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FOREWORD 

One  of  the  priority  goals  of  the  U.S.  Army  Test  and  Evaluation 
Command  (TECOM)  Methodology  Program  is  to  improve  the  timeliness 
and  quality  of  test  capabilities.  TECOM  has  tasked  the  U.S.  Army 
Electronic  Proving  Ground  (USAEPG)  in  its  current  modernization 
plan  to  support  this  effort. 


This  final  report  documents  a  USAEPG  methodology  impovement 
investigation  to  identify  methods  to  partially  automate  assimila¬ 
tion  of  data  from  U.S.  Army-standard  data  bases  for  the  develop¬ 
ment  of  and  integration  into  a  communication  equipment  operator 
data  base  for  driving  battlefield  simulation  and  modeling. 


1.1  BACKGROUND .  The  electronic  battlefield  is  growing  increas¬ 
ingly  complex.  The  rapid  advance  in  communications  equipment 
technology  is  reflected  in  the  growing  requirement  for  detailed 
knowledge  of  the  effects  of  Electromagnetic  Compatibility  (EMC) 
and  Electromagnetic  Vulnerability  (EMV)  on  the  ability  of  engaged 
forces  to  communicate  on  the  battlefield. 

Modem  electronic  devices  have  an  inherently  high  unit  cost,  and 
communications  systems  for  battle  require  large  numbers  of  device 
units.  Direct  testing  of  new  systems  became  prohibitively 
expensive.  TECOM  gained  economy  and  flexibility  in  test  programs 
by  adopting  an  additional  test  methodology,  numerical  simulation, 
to  produce  data  representative  of  full-scale  field  tests. 

The  simulations  require  a  computerized  representation  of  every 
emitter  and  receptor  on  the  battlefield.  The  extensive  data  base 
generation  needed  to  support  large-scale  simulations  limited  the 
scope  and  responsiveness  of  test  programs.  Partial  automation  of 
the  data  base  generation  process  was  accomplished  by  separating 
the  data  base  information  requirement  into  two  parts:  the 
relatively  small  generic  unit  files  and  the  larger  deployment 
files.  The  generic  unit  files  were  prepared  manually  and  then 
input  to  a  computer  program  which  automatically  generated  the 
deployment  files.  This  program,  the  Communication-Electronic 
Operator  Positioning  System  (CEOPS) ,  automated  the  generation  of 
multiple  "snapshots"  of  the  battlefield  based  on  manual  changes 
to  the  generic  unit  files.  The  "snapshots"  are  called  Simulated 
Tactical  Deployments  (STDs) . 

The  manually  prepared  generic  unit  files  identify  the  types  and 
quantities  of  personnel,  vehicles  and  equipment  comprising  each 
unit.  The  equipment  loaded  on  each  vehicle  must  also  be 
identified  in  the  data  base.  Data  for  this  purpose  is  received 
at  least  quarterly  from  several  Army-Standard  data  bases  and  must 
be  printed,  analyzed,  integrated,  and  manually  entered  into  the 
generic  unit  files.  These  activities  are  manpower- intensive.  It 
is  necessary  to  automate  these  activities  as  much  as  possible. 

1.2  OBJECTIVES .  The  objective  of  this  investigation  is  to 
design  procedures  for  comparing  and  integrating  data  files  from 
several  Army-Standard  Force  Modernization  and  Inventory  Data 
Bases  and  to  develop  procedures  for  automating  the  Battlefield 
Electomagnetic  Environments  Office  (BEEO)  data  preparation  and 
data  base  maintenance  process,  using  the  integrated  data  files. 
The  integration  will  include  partial  automation  of  the  process  of 
identifying  and  resolving  discrepancies  and  anomalies  in  the 
data. 

The  objectives  imply  a  requirement  for  a  computer  system, 
including  data  base,  hardware  and  software.  Based  on  a  trade 
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study,  the  VAX  11/785,  VAX/VMS,  and  the  INGRES  Data  Base 
Management  System  were  selected.  A  secondary  objective  was  to 
document  software  developed  as  a  result  of  this  investigation. 

1.3  summary  OF  procedures.  The  following  procedures  were  used 
in  order  to  design  automated  procedures  to  achieve  the 
obj ectives. 

1.3.1  Desicm-to-Obiective  Procedures.  The  scope  of  the 
investigation  was  restricted  to  methods  for  the  preparation  of 
Generic  Unit  Files  for  simulation  of  U.S.  Army  forces  using  the 
Force  Modernization  Data  Base  as  the  sdurce  specifying 
organization  and  equipment. 

The  data  files  from  several  Army-Standard  Force  Modernization  and 
Inventory  Data  Bases  were  compared  and  integrated  by  hand  and  by 
computer.  The  files  were  examined  for  the  existence  of  similar 
data  elements  which  would  allow  discrepancies  and  anomalies  to  be 
identified  and  resolved  in  a  partially  automated  fashion.  The 
files  were  also  examined  for  common  keys  which  would  allow  them 
to  be  cross-referenced.  Procedures  for  automating  the  file 
comparison/integration/maintenance  process  using  these  files  were 
considered  for  automation. 

1.3. 1.1  Identify  Current  Needs  of  Simulated  Tactical  Deployment 
Generation  Systems.  The  purpose  of  this  procedure  was  to  develop 
a  standard  for  the  evaluation  of  the  product  of  this  investi¬ 
gation.  The  effort  was  principally  directed  toward  the  input 
requirements  of  the  Performance  Analysis  for  Communication- 
Electronic  Systems  (PACES)  Model  rim  on  the  Cyber  180-830  of  the 
Electromagnetic  Environment  Test  Facility  (EMETF) .  CEOPS  used  by 
the  EMETF,  Fort  Huachuca,  Arizona,  and  the  Deployment  Generation 
System  (DGS) ,  used  by  the  BEEO,  Alexandria,  Virginia  were 
examined . 

The  functions  of  GUF  operator  records  were  identified. 

1.3. 1.2  Identify  the  Results  of  Previous  Efforts.  The  purpose 
of  this  procedure  was  to  avoid  duplication  of  work  and  to  assure 
that  existing  generic  unit  files  and  related  files  would  remain 
usable.  The  investigators  identified  and  evaluated  in-house 
efforts  of  the  BEEO.  This  evaluation  would  also  provide  insight 
into  the  expected  direction  of  the  BEEO  modeling  and  simulation 
data  base  effort. 

1.3. 1.3  Identify  and  Limit  the  Sources  of  Data  Elements.  The 
purpose  of  this  procedure  was  to  define  the  inputs  to  the 
computer  program  product.  A  review  of  various  Army-standard  data 
bases  was  conducted.  The  data  available  from  each,  its 
applicability,  and  currency  was  assessed.  A  specific  data 
selection  criterion  was  established. 
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1.3. 1.4  Develop  Techniques  to  Collect  and  Maintain  Data  Elements 
of  Interest  to  the  Data  Base  Effort.  The  purpose  of  this 
procedure  was  to  define  the  functions  of  the  computer  program. 

The  contents  of  selected  Force  Modernization  data  files  were 
examined.  Record  selection  criteria  were  formulated  and 
programmed.  A  data  file  for  extracted  records  was  designed. 

1.3.*.  Software  Design  Procedures.  A  methodology  was  formulated 
to  identify  those  functions  which  were  suitable  for  automation. 

A  Generic  Data  System  was  developed  consisting  of  the  Generic 
Unit  Entry  System  (GUES)  and  the  Generic  Data  Entry  System 
(GOES) .  The  requirements  for  this  software  are  specified  in  the 
appendix,  "Software  Requirements  Specification  for  the  Generic 
Data  Base  System . " 

1.3. 2.1  GUES  Design  Procedures.  A  program  was  developed  based 
on  the  identified  requirements,  taking  advantage  of  existing  data 
files  maintained  by  the  BEEO. 

It  was  required  that  the  human-machine  interface  provide  the 
Military  Analyst  with  supervisory  control  over  the  association  of 
operators,  equipment,  vehicles  and  antenna. 

1.3. 2. 1.1  Identify  the  Functions  of  Operator  Records.  The 
investigators  identified  those  consistent  constraints  for  the 
building  of  data  base  operator  records  that  could  be  retained  in 
software  routines  and  data  tables. 

These  constraints  were  incorporated  into  a  computer  program  to 
facilitate  the  association  of  operators,  vehicles  (or  platforms) , 
and  communications  equipment. 

The  program  was  designed  to  allow  equipment  to  be  further 
associated  with  its  various  components  and  antennas  with  a 
minimum  of  Military  Analyst  intervention. 

1.3. 2. 2  GOES  Design  Procedures.  The  purpose  of  GDES  was  to 
reduce  both  the  calendar  time  and  the  manhour  resource 
requirement  in  generic  unit  file  preparation  process. 

An  ability  to  easily  manipulate  the  data,  make  decisions  during 
the  building  process,  and  manually  enter  data  was  required. 

A  catalogue  of  error  cases  for  manual  data  entry  was  prepared  to 
explore  those  areas  where  error  checking  and  data  validation 
where  appropriate. 

Compatibility  with  CEOPS  was  established  as  a  requirement. 

1.3.3  Project  Technical  Procedures.  Preparatory  to  final 
software  design  decisions  a  chart  was  prepared  in  the  form  of  a 
matrix.  There  was  a  row  for  each  of  the  systems:  DGS ,  CEOPS 
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(without  GDES) ,  and  CEOPS  (with  GDES) .  There  was  a  column  for 
each  relevant  simulation  methodology  function.  After  GUES  was 
developed,  it  was  added  to  the  matrix,  the  result  is  shown  in 
figure  3,  page  16. 

1.4  SUMMARY  OF  RESULTS.  The  ultimate  result  of  this 
investigation  consisted  of  the  computer  programs  GUES  and  GDES. 
One  intermediate  result  precipitated  this  ultimate  result.  The 
intermediate  result  consisted  of  recognition  of  deficiencies  of 
data  base-directed  automation  schemes. 

1.4.1  Data  Base-Directed  Automation. 

1.4. 1.1  Sources  of  Data  Elements.  It  was  established  that  the 
sources  must  be  currently  available,  without  imposing  additional 
requirements  upon  agencies  responsible  for  those  sources.  The 
following  sources  were  selected. 

1.4. 1.1.1  Table  of  Organization  and  Equipment.  The  VTAADS  data 
(Force  Modernization  Data  Base)  for  Tables  of  Organization  and 
Equipment  (TOEs)  is  also  available  on  a  data  tape.  This  data 
file  forms  the  lowest  level  of  definition  required  for  the 
construction  of  a  generic  military  unit  and  reflects  a  wide  range 
of  actual  and  notional  organizations  which  may  be  of  interest  in 
a  modeling  and  simulation  effort.  Extraction  of  data  from  this 
source  may  be  accomplished  in  a  straightforward  manner  and  made 
available  as  input  to  the  generic  operator  building  process. 

1.4. 1.1. 2  Supply  Bulletin.  The  Supply  Bulletin  (SB  700-20)  is 
available  from  the  responsible  agency  on  a  data  tape  which 
uniquely  identifies  all  items  of  equipment  which  appear  in  a 
Table  of  Organization  and  Equipment.  While  a  vast  amount  of  data 
is  contained  in  the  file,  suitable  filtering  reduces  the  data  to 
a  manageable  volume.  Minimal  manual  manipulation  of  the  data  is 
required.  A  procedure  is  in  effect  by  the  responsible  agency 
that  facilitates  routine  monitoring  of  the  currency  of  the  data 
provided. 

A  computer  program  was  written  to  reduce  the  supply  bulletin  data 
and  procedures  developed  to  cross  reference  it  to  the  code  book 
and  TOE  files. 

1.4. 1.1. 3  Existing  In-House  Data  Files.  Significant  effort  had 
been  made  by  the  BEEO,  both  prior  and  subsequent  to  the  develop¬ 
ment  of  the  DGS,  in  the  definition  of  those  equipment  items,  from 
the  SB  700-20,  which  made  up  the  platforms  and  equipment  items  to 
be  represented  in  the  generic  operator  record.  Additionally, 
look-up  tables  had  been  developed  defining  vehicle,  equipment, 
component,  and  antenna  associations  which,  while  not  complete, 
were  a  sound  basis  for  task  development  and  represented  a  large 
percentage  of  the  generic  U.S.  force  data.  The  data  was 
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completely  preserved,  although  the  format  for  storage,  use,  and 
display  of  this  data  was  changed. 

1.4. 1.2  Techniques  to  Collect  and  Maintain  Data  Elements  of 
Interest  to  the  Data  Base  Effort.  In  each  instance,  the  data 
available  exceeded  the  requirement  for  this  specific  data  base. 
The  record  selection  program  was  used  to  extract  the  relevant 
data. 

Computer  program (s)  necessary  to  read  the  TOE  data  and  build 
lists  of  operator/equipment/vehicle/antenna  associations  were 
written.  These  lists  would  reflect  the  use  of  the  unit's 
assigned  equipment. 

1.4.2  Generic  Unit  Entry  System.  GUES  automated  several 
doctrine  application  functions.  Analyst  choices  were  displayed 
as  multiple,  independently  scrollable  data  tables  (windows) . 
Analyst  choice  selection  was  input  by  keyboard-controlled  cursor 
movement:. 

1.4. 2.1  GUES  Functions.  The  following  functions  of  operator 
records  were  identified:  association  of  vehicle,  operators, 
equipment  and  antennas;  compatibility  of  vehicles,  equipment 
and  antennas;  tracing  equipment  items  to  the  doctrine 
documentation  for  their  issue;  tracing  personnel  to  doctrine 
documentation  for  issue;  listing  the  components  of  radio 
frequency  (RF)  equipment  end  items;  association  of  operators  with 
communication  nets;  coding  of  identifiers  for  operators, 
vehicles,  RF  equipment  and  antennas. 

These  functions  are  automated  in  GUES,  with  the  following 
qualifications.  Automation  depends  on  maintenance  of 
configuration  files  and  an  antenna/vehicle  compatibility  file. 
Association  of  antennas  with  equipment  is  an  analyst  selection 
from  a  list  of  compatible  antennas.  Association  of  operators 
with  nets  is  not  automated. 

At  the  beginning  of  the  user  session,  association  of  RF  equipment 
with  vehicles  is  an  analyst  selection  from  choices  determined  by 
the  type  and  number  of  issued  RF  equipment  and  by  the 
configuration  file.  After  the  association  is  done  for  a  vehicle, 
the  number  of  choices  for  the  remaining  vehicles  is  reduced. 

1.4. 2. 2  GUES  Inputs .  The  primary  input  is  the  tables  of 
vehicles,  personnel  and  RF  equipment  which  was  extracted  from  the 
VTAADS  data  base.  Additional  input  is  from  the  equipment  and 
component  definition  files  and  from  the  antenna  compatibility 
file. 

1.4. 2. 3  GUES  Outputs.  The  primary  output  is  the  operator 
records,  which  are  directly  compatible  with  GDES  data  editing  and 
report  generation  functions.  GDES  compatibility  in  turn  provides 
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CEOPS  compatibility,  provided  that  net  definitions  (net  header 
records)  are  added  to  the  GUES  outputs. 

The  Ingres  data  base  management  system  allows  update  of  the 
configuration  file  and  compatibility  file. 

Operator  records  output  by  GUES  do  not  include  codes  for 
communications  security  (COMSEC)  devices. 

1.4.3  Generic  Data  Entry  System.  GDES  reduced  both  the  calendar 
time  and  the  manhour  resource  requirement  in  CEOPS  simulations. 
This  was  accomplished  by  moving  data  checking  and  data  validity 
verification  to  an  earlier  point  in  the  simulation  process. 

GDES,  an  intelligent  data  entry  system  partially  automates  data 
coding  and  certain  other  doctrine  application  functions. 

GDES  was  placed  into  service  and  successively  used  for 
preparation  of  several  simulation  data  bases. 

1.4. 3.1  GDES  Functions.  GDES  automatically  prevent  some  coding 
errors,  detects  other  errors  immediately  after  the  erroneous  data 
is  entered,  and  automatically  assures  certain  data  integrity 
constraints. 

1.4. 3. 2  GDES  Inputs.  GDES  eliminates  the  necessity  for  coding 
forms.  Instead,  the  user  enters  data  interactively. 

1.4. 3. 3  GDES  Outputs.  The  primary  GDES  outputs  are  CEOPS- 
compatible  generic  unit  files  and  summary  reports. 

Programmed  data  entry  forms  were  used  to  develop  the  human- 
machine  interface.  The  result  was  a  menu  driven,  "fill  the 
blanks"  system  that  performed  on-line  data  validity  checking  and 
help  throughout  the  work  session.  The  Military  Analysts  were  led 
through  the  data  entry  process  in  a  logical,  easily  learned  way. 

1.4.4  Results  of  Previous  Efforts . 


1.4.4. l  In-House  BEEP  Software.  The  listings  of  the  supply 
bulletin  filter  showed  that  it  was  possible  to  automatically 
reduce  the  supply  bulletin  data,  partially  selecting  vehicles  and 
RF  equipment  of  interest. 

The  listing  of  the  equipment  inventory  program  showed  that  is  was 
feasible  to  use  a  supply  bulletin  extract  to  automatically  select 
equipment  of  interest  from  the  VTAADS  TOE  file. 

The  listing  of  the  vehicle  configuration  program  showed  that  it 
was  feasible  to  list  the  components  of  the  RF  equipment  of 
interest  by  analyzing  defined  vehicle  configurations.  It  also 


I 


showed  that  antenna  candidates  could  be  retrieved  from  a 
vehicle/component/antenna  interoperability  file. 

1.4. 4. 2  Generic  Unit  Files.  A  conservative  data  base  design 
philosophy  assured  upward  compatibility  of  the  old  GUFs. 

Operator  information  was  left  joined  to  antenna,  equipment  and 
net  information.  The  code  book  was  retained. 

1.5  ANALYSIS.  The  candidate  Army-Standard  Data  Bases  were 
compared,  in  form  and  content,  to  the  identified  STD  generation 
system  software  requirements.  The  automated  functions  available 
using  GUES  and  GDES  were  compared  to  the  functions  required  for 
the  preparation  of  STDs.  The  results  are  shown  in  the  Function 
Automation  Matrix,  page  16.  The  GDES  program  was  placed  in  full 
service  and  its  effectiveness  was  judged  by  the  resulting 
simulation  usage.  The  GUES  program  was  run  against  a  test  case 
generic  unit  file  wich  had  been  prepared  by  current  methods. 

1.6  CONCLUSIONS .  Automated  procedures  for  extraction  of 
operator  records,  vehicles,  and  RF  equipment  have  been  developed. 
These  procedures  depend  on  maintenance  of  an  RF  equipment 
identifier  table  by  non-automated  inspection  of  the  Supply 
Bulletin.  The  Army-Standard  Data  Bases  do  not  possess  the  data 
elements  and  data  values  required  for  automation  of  most  Generic 
Unit  File  functions. 

1.7  RECOMMENDATIONS .  The  recommendations  fall  into  four 
categories:  data  base,  automated  procedures,  supporting  manual 
procedures,  and  coordination. 

1.7.1  Data  Base  Recommendations.  The  VTAADS  TOE  should  be  used 
as  the  primary  data  source  for  automatic  data  extraction  when 
applicable.  For  simulations  to  which  VTAADS  does  not  apply,  a 
stand-alone  table  of  vehicles,  operators,  and  RF  equipment  should 
be  constructed  and  used  in  its  place. 

For  successful  data  base  automation,  additional  supplemental  data 
files  should  be  constructed  and  maintained.  These  secondary 
files  should  include  a  normalized  table  of  vehicle  configur¬ 
ations,  a  table  showing  the  component  compositon  of  major  RF 
equipment  items,  a  vehicle/antenna  compatibility  table,  and  a 
component/antenna  compatibility  table.  A  table  of  standard 
avionics  sets  should  be  included  to  supplement  VTAADS  when  VTAADS 
is  used. 

1.7.2  Automated  Procedures.  The  programs  GUES  and  GDES  should 
be  incorporated  into  the  BEEO  Library  and  used  for  preparing 
GUFs.  The  two  programs  should  be  combined  so  that  their 
automated  functions  can  be  used  together  for  substantially 
complete  automation. 


1.7.3  Supporting  Manual  Procedures.  Personnel  should  be 
assigned  to  maintain  the  secondary  data  files  specified  in 
paragraph  1.7.1. 


1.7.4  Coordination.  The  results  of  the  parametric  data  base 
investigation  should  be  applied  to  the  equipment  composition 


IDENTIFY  CURRENT  NEEDS  OF  SIMULATED  TACTICAL  DEPLOYMENT 
GENERATION  SYSTEMS.  CEOPS,  used  by  the  EMETF,  and  DGS ,  used  by 
BEEO,  was  reviewed  by  document  study,  user  and  programmer  inter¬ 
view  to  determine  respective  data  element  requirements. 

2.2  IDENTIFY  AND  LIMIT  THE  SOURCES  OF  DATA  ELEMENTS.  A  specific 
criterion  was  established  that  the  sources  must  be  currently 
available,  without  imposing  addition  requirements  upon  agencies 
responsible  for  those  sources. 

The  initial  effort  of  the  investigation  was  directed  toward  the 
data  available  from  the  Supply  Bulletin  (SB  700-20)  obtained  from 
Army  Material  Command  (AMC)  on  magnetic  tape.  This  file  contains 
data  on  equipment  items  (including  vehicles)  authorized  for  pub¬ 
lication  as  issue  equipment  in  the  Table  of  Organization  and 
Equipment  for  the  various  U.S.  Army  units.  A  data  key  exists  in 
the  Supply  Bulletin  (LIN)  which  is  common  to  the  TOE  files. 

The  TOE  file  (VTAADS)  uses  the  data  element  LIN  in  the  equipment 
records.  Therefore,  it  was  determined  that  compiling  the 
appropriate  LINs,  from  the  supply  bulletin,  into  a  look-up  table 
would  facilitate  extracting  items  of  interest  from  the  TOE  file 
for  the  partial  automation  of  the  generation  of  operator  records. 

Table  of  Organization  and  Equipment  data,  available  from  TRADOC, 
is  furnished  on  magnetic  tape.  These  files  are  very  large,  and 
contain  information  on  units  in  varying  stages  of  development. 

It  was  assumed  that  testing  may  be  necessary  for  various  notional 
as  well  as  actual  units;  therefore,  no  effort  was  made  to  filter 
the  data. 

VTAADS  TOE  files  are  produced  and  distributed  quarterly.  The  SB 
700-20  data  is  similarly  available.  Vehicle  configuration  files 
were  produced  in-house  by  BEEO. 

2.3  IDENTIFY  THE  RESULTS  OF  PREVIOUS  EFFORTS.  The  in-house  BEEO 
software  was  received  as  program  source  code,  without  documenta¬ 
tion.  Techniques  for  "reverse  engineering”  the  source  code  were 
developed  to  identify  the  intended  functions  of  the  programs. 

The  software  included  a  supply  bulletin  filter,  a  VTAADS  data 
extraction  program  and  a  vehicle  configuration  processor.  The 
identified  functions  formed  the  starting  point  for  the  design  of 
GUES. 


2.4  DEVELOP  PROCEDURES  TO  COLLECT  AND  MAINTAIN  DATA  ELEMENTS  OF 


INTEREST  TO  THE  DATA  BASE  EFFORT.  An  effort  to  extract  the  LINs 
applicable  to  vehicles,  RF  equipment,  COMSEC  equipment,  and 
antennas  was  undertaken.  The  starting  point  for  this  effort  was 
provided  by  in-house  developed  software  from  BEEO.  The  BEEO 


software  illustrated  certain  concepts  and  rules  for  the  selection 
of  those  data  items  which  would  facilitate  the  identification  of 
most  of  the  LINs  of  interest  to  the  operator  building  process. 

It  may  be  noted  that  many  anomalies  exist  in  the  assignment  of 
data  items,  such  as  National  Stock  Number;  however,  the  result  of 
the  computer  filter  was  largely  successful.  Even  though  several 
hundreds  of  items  were  selected  by  the  test,  it  was  a  fairly 
simple  matter  to  further  categorize  each  selected  item  according 
to  the  USAEPG  Codebook  Methodology.  Using  the  facilities  of  the 
computer  editor  and  the  INGRES  DBMS,  the  remaining  items  were 
easily  found  and  related  to  the  codes  currently  used  (where 
applicable) .  Additionally,  a  number  of  items  were  found  that  can 
be  reasonably  expected  to  be  of  future  interest  even  though  not 
currently  recognized  in  the  present  codebook. 

Extracting  data  from  the  VTAADS  TOE  files  for  a  given  unit  or  set 
of  units  can  easily  be  accomplished  in  any  of  several  methods. 
These  extractions  become  the  input  for  the  (partially)  automated 
operator  building  process  and  are  made  according  to  the  require¬ 
ments  of  the  task  at  hand. 

2.5  DEVELOP  A  COMPUTER  PROGRAM  TO  PARTIALLY  AUTOMATE  THE 
PRODUCTION  OF  GENERIC  OPERATOR  RECORDS.  A  software  program, 

GUES,  was  defined  and  developed  for  the  following  functions: 

o  automatic  selection  of  vehicles  and  electronic  RF 
devices 

o  automatic  selection  of  legal  vehicle/platform  configura¬ 
tion  lists 

o  automatic  equipment  composition/ decomposition 
o  menu  selection  of  interoperable  antennas 
o  automatic  look-up  of  operator  codes 

The  automatic  selection  of  configurations  function  allows  the 
user  to  operate  on  the  vehicles  and  RF  electronic  devices  of  a 
single  paragraph  at  a  time.  After  the  analyst  manually  selects  a 
configuration  from  the  list,  the  list  of  possible  configurations 
is  re-computed  to  take  into  account  the  reduction  in  equipment 
available  for  assignment.  Thus,  the  fewer  and  fewer  choices  are 
required  as  the  operation  continues. 

The  menu  selection  of  interoperable  antennas  function  depicts  the 
entire  complement  of  vehicles,  with  the  assigned  RF  electronic 
devices  and  interoperable  antennas  for  the  current  selection,  on 
a  graphic  display.  The  choices  on  the  display  are  determined  by 
the  interoperability  file  PTAB.  Refer  to  the  Data  Base  Design 
Document,  Appendix  D. 


The  operator  code  look-up  function  displays  codes  from  the 
codebook  file  and  allows  the  desired  code  to  be  either  selected 
using  the  cursor  or  directly  typed  in. 


|  «tM*M '  fcltjl  m ,M*Ty  »,#  -y-k  J 


l.t  «.>  4.*  4.1  LI  »->  IJ  l.t  M  «.! 


■JJlJ 

iSi» 

IV' 

•s 


A  software  program  for  automatic  selection  of  vehicle/platform 
configuration  to  maximize  RF  activity  was  defined.  However,  the 
feasibility  could  not  be  verified  in  the  absence  of  a  suitable 
configuration  file.  Therefore,  this  program  was  not  developed. 

2.5.1  Software  Design. 
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2.5. 1.1  Data  Base  Design.  The  BEEO  configuration  file  was 
examined  for  functional  dependencies.  It  was  seen  that  the 
component  and  eguipment  fields  were  functionally  independent,  and 
that  the  same  configuration  definition  could  be  used  for  various 
kinds  of  vehicles.  Therefore,  the  equipment/component  relation 
was  extracted  and  put  into  a  separate  data  base  table  EQP_DEF. 

In  addition,  the  configuration  references  were  separated  from  the 
configuration  definitions,  replacing  the  configuration  file  with 
two  files,  CONFIG_DEF  and  CONFIG_REF.  The  vehicle/component/ an¬ 
tenna  compatibility  file  of  the  EMETF  was  normalized  in  a  similar 
fashion.  Refer  to  the  Data  Base  Design  Document,  Appendix  D. 

2. 5. 1.2  Internal  Data  Structures.  Linked  list  structures  were 
chosen  to  represent  partial  GUF  records.  This  structure  allows 
flexible  handling  of  incomplete  and  variable  sized  data. 
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The  programming  for  the  function  described  above  was  accomplished 
in  the  PRUNE  module  which  is  coded  in  PASCAL  and  uses  linked 
lists.  The  PRUNE  module  and  the  linked  list  utilities  will  be 
documented  in  "Software  Detailed  Design  Document  for  Generic  Data 
System. " 

2.6  DETAILED  REQUIREMENTS  ANALYSIS.  This  section  analyzes 
functions  of  the  simulation  methodology  which  have  been  automat¬ 
ed,  or  may  be  automated  for  cost  savings. 

The  battlefield  modeling  requirements  were  analyzed  by 
constructing  dependency  networks.  For  example,  the  chart  "Net 
Assignment  requirements  Network"  shows  how  performance  scores 
depend  on  preparation  of  generic  unit  data,  specification  of 
generic  and  specific  unit  relationships,  and  compilation  of  lists 
of  specific  units.  Collectively,  these  functions  are  referred  to 
as  organizational  relationship  application  (ORA) .  The  chart 
applies  to  any  system  which  uses  generic  unit  ,files  and  performs 
semi-automatic  net  assignment.  It  explains  the  justification  for 
ORA. 

The  chart  "Doctrine  Application  Requirements  Network"  explains 
the  requirements  for  universal  doctrine  satisfaction,  doctrine 
research  and  traceability,  doctrine  research  result  preservation 
and  equipment  utilization.  Doctrine  application  refers  to  the 
incorporation  of  doctrinal  associations  between  personnel, 
vehicles,  and  RF  equipment  into  the  battlefield  model. 
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a  communication  network. 

"Requirements  Network"  refers  to  functional  dependency. 

Figure  1.  NET  ASSIGNMENT  REQUIREMENTS  NETWORK 

Universal  doctrine  satisfaction  means,  for  example,  making  sure 
that  every  net  has  a  proponent  unit  and  a  net  control  station. 


Proper  equipment  utilization  includes  basis  of  issue, 
interoperability,  specification  of  technical  parameters,  and 
listing  the  equipment  components  (also  called  equipment 
decomposition) .  Basis  of  issue  means  making  sure  that  the  issued 
equipment  and  personnel,  and  only  the  issued  equipment  and 
personnel,  are  put  into  the  model. 
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Figure  2.  DOCTRINE  REQUIREMENTS  NETWORK 

Interoperability,  used  here,  means  that  doctrine  and  device 
characteristics  will  allow  two  pieces  of  equipment  to  be  used 
together.  For  example,  two  radios  which  operate  in  the  same 
frequency  band  and  use  the  same  modulation  are  interoperable  with 
one  another.  Similarly,  a  radio  which  may  be  mounted  in  and 
powered  by  a  particular  vehicle  is  interoperable  with  that 
vehicle.  The  term  "interoperability"  is  used  instead  of 
"compatibility”  to  avoid  confusion  with  "electromagnetic 
compatibility. " 

Technical  parameters  include  transmitter  power,  frequency  band 
and  modulation.  For  radar  systems,  they  include  pulse  frequency 
and  width. 

Most  of  the  requirements  given  here  include  data  coding,  the 
assignment  of  unique  identifiers  to  objects  in  the  battlefield, 
and  the  recording  of  associations  between  the  objects. 


Research  result  preservation  means  record-keeping  in  order  to 
prevent  duplication  of  research  effort.  For  example,  validated 
combinations  of  vehicles,  equipment  and  antennas  may  be  recorded 
for  future  reference.  Due  to  the  large  number  of  data,  research 
result  preservation  schemes  have  had  limited  application. 

The  ORA  function  allows  many  functions  to  be  automated  at  the 
level  of  specific  uni-ts  (deployment  level)  .  ORA  includes  the 
integration  of  inter-unit  command/control/ support  relationships 
between  military  units  into  a  numerical,  computer  readable 
representation  of  the  battlefield.  ORA  may  also  include 
specification  of  the  geographic  positions  of  RF  equipment  and 
operators  relative  to  their  unit  boundaries. 

These  derived  requirements  may  be  used  to  compare  the  four 
computer  programs  used  to  partially  automate  the  preparation  of 
generic  unit  files,  as  shown  in  figure  3,  " FUNCTION  AUTOMATION 
MATRIX" .  The  columns  of  the  matrix  are  the  four  programs  and  the 
rows  of  the  matrix  are  the  functions.  The  characters  placed  in 
the  matrix  indicate  the  degree  of  automation. 
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Figure  3.  FUNCTION  AUTOMATION  MATRIX 


2. 7. 1.1  Supply  Bulletin.  The  Supply  Bulletin  required  filtering 
and  incorporation  into  a  local  data  base  for  cross-reference  to 
the  code  book.  This  activity  is  required  only  once.  Future  up¬ 
date  to  the  resulting  line  numbers  table  will  be  handled  by  the 
normal  INGRES  data  table  maintenance  procedures  .  A  side  effect 
of  the  investigation  resulted  in  the  production  of  a  version  of 
the  Supply  Bulletin  reduced  to  generic  records  that  are 
convenient  for  research. 

2.7. 1.2  VTAADS  TOE.  The  TOE  files  represent  an  authoritative 
source  of  information.  While  the  files  are  quite  large,  the 
structure  is  easily  understood  and  easy  to  work  with.  The  TOE 
files  do  have  a  few  shortcommings .  The  two  most  notable  problems 
are  currency  and  avionics  equipment.  The  matter  of  currency  is 
due  largely  to  the  size  of  the  data  base.  Data  tapes  are 
produced  and  distributed  quarterly,  however,  a  full  years  worth 
of  data  updates  are  required  for  a  complete  data  base  update. 
Therefore,  data  selected  may  be  up  to  one  year  old.  The  avionics 
equipment  on  board  an  aircraft  is  not  reflected  in  the  TOE  since 
this  is  a  part  of  the  aircraft  as  issued. 

2. 7. 1.3  VTAADS  VBIOP.  The  VBOIP  is  not  available  for  applica¬ 
tion  as  uploadable  data.  It  is  possible  to  make  on-line  requests 
for  TOEs  with  the  BOIP  applied,  however,  the  result  is  received 
as  hard  copy.  This  is  a  valuable  aid  to  the  Military  Analyst 
making  direct  data  entry  adjustments  to  the  data  base. 

2. 7. 1.4  JETDS .  The  Joint  Electronic  Type  Designation  System 
Data  Base  is  valuable  for  equipment  decomposition.  The  data  base 
information  is  available  on-line  as  well  as  the  previous 
microfilm  version,  however,  it  is  not  available  for  upload.  It 
is  the  most  current  equipment  source  available. 

2.7.2  Automation  Effectivness  Conclusions.  Many  of  the 
methodology  elements,  applicable  to  generic  unit  files,  have  been 
automated  in  the  programs  GUES  and  GDES.  Neither  program 
automates  the  methodology  completely. 

2.8  detailed  RECOMMENDATIONS .  This  section  recommends 
additional  operating  procedures,  data  file  construction,  and 
software  requirements. 


2.8.1  Enhance  the  System  Capability.  In  GDES,  the  line 
number/code  book  cross  reference  table  should  be  used  for  auto¬ 
matic  code  lookup  and/or  verification.  The  equipment  decomposi¬ 
tion  function  should  be  added  by  using  the  equipment  composition 
table.  Therefore,  military  analyst  time  should  be  allocated  for 
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the  validation  and  maintenance  of  these  tables.  Extensions 
should  be  planned  for  non-VTAADS  and  non-U. S.  Army  unit  data 
construction 1 

Equipment  should  be  automatically  cross-referenced  to  a  data  file 
supporting  the  technical  parameter  identification  function. 

The  current  research  result  preservation  methods  should  be 
enhanced  to  reduce  the  manual  research  process  and  assist  in  the 
maintenance  of  supporting  data  base  tables. 

2.8.2  TOE  Data  Currency  and  Update.  Develop  an  ability  to  apply 
the  Basis  of  Issue  Plan  to  the  TOE  data  in  order  to  reflect  the 
most  current  planning  data  in  the  system  input.  As  of  this  time 
the  VTAADS  TOE  data  is  received  in  various  states  of  completion 
and  in  forms  of  various  notional  units.  It  is  desirable  that  the 
units  to  be  simulated  accurately  reflect  the  equipment  and  the 
environment  to  be  tested. 

2.8.3  Incorporation  of  Non-TOE  Data.  The  avionics  equipment 
that  is  integral  to  aircraft,  for  example,  is  not  reflected  in 
the  TOE.  Much  of  this  equipment  is  of  interest  to  communications 
modeling  and  simulation,  represents  a  significant  number  of 
communications  operators,  and  must  be  incorporated  in  the  data 
base.  A  facility  to  reflect  this  "Standard  Avionics  Set"  is 
required  for  a  credible  system. 

2.8.4  Report  Generation.  The  facility  made  available  by  the 
INGRES  DBMS  suggests  that  redesign  and  improvement  of  the  reports 
generated  should  be  considered.  The  usability  and  readability  of 
reports  can  be  improved.  Reports  now  presented  to  the  various 
users  contain  a  significant  amount  of  coded  information.  It  has 
been  shown  that  "plain  text"  reports  are  more  usable,  and  that 
the  facility  now  exists  to  product  a  more  "plain  text"  report. 
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Methodology  Investigation  Proposal  and  Directive 
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March  1586 


METHODOLOGY  INVESTIGATION  PROPOSAL 

1.  TITLE .  Automated  Analysis  and  Entry  of  U.S.  Generic-Unit  Data 

2.  CAT SGORY .  DA  Mission  Areas  supported  include  electromagnetic 
Compatibility  Program  (EMCP)  and  Electromagnetic  Compatibility/ Vulner¬ 
ability  analysis.  This  investigation  focuses  on  improvements  in 
database  research,  analysis,  integration,  modeling. 

3.  INSTALLATION  OR  FIELD  OPERATING  ACTIVITY  (I/FOA).  U.S.  Army 
Electronic  Proving  Ground  (USAEPG),  Fort  Huachuca,  Arizona  85613-7110 
and  USAEPG/Battlef ield  Electromagnetic  Environments  Office  (BEEO), 
Alexandria,  Virginia  22333-0001 

4.  PRINCIPAL  INVESTIGATOR.  Mr.  C.  Louis  Deibel,  BEEO,  STEEP-MT-DB , 
AUTOVON  284-8515 

5.  STATEMENT  OF  THE  PROBLEM.  BEEO  presently  uses  manpower-intensive 
procedures  for  data  integration  and  database  maintenance.  These 
manual  procedures  severely  limit  the  scope  and  responsiveness  of  the 
BEEO  operations.  BEEO  does  not  have  the  capability  to  provide  routine, 
timely  support  to  large  simulation  and  testing  projects  without 
incurring  unacceptably  high  personnel  costs. 

6.  BACKGROUND ,  Large-scale  battlefield  simulation,  v/hich  are  essen¬ 
tial  for  realistic  EMC/EMV  analysis,  consist  of  thousands  of  U.S. 
military  units-  The  BEEO  databases  which  support  these  simulations 
must  identify  the  types  and  quantities  of  personnel,  vehicles,  and 
equipment  comprising  each  unit.  The  personnel  and  equipment  associated 
with  ("loaded  on")  each  vehicle  must  also  be  identified  in  the  data¬ 
base.  Data  is  received  at  least  quarterly  from  several  Army-standard 
databases  and  must  be  printed,  analyzed,  and  integrated  by  BEEO 
personnel.  New  data  must  then  be  entered  manually  to  update  the  BEEO 
databases.  Data  analysis, integration,  and  entry  is  manpower-intensive. 
Computer  software  is  needed  to  reduce  the  cost  and  improve  the  respon¬ 
siveness  of  database  maintenance  operations. 

7.  GOAL. 

a.  To  design  procedures  for  comparing  and  integrating  data  files 
from  several  Army-Standard  Force  Modernization  and  Inventory  Databases. 
The  integration  will  include  partial  automation  of  the  process  of 
identifying  and  resolving  discrepancies  and  anomalies  in  the  data. 

b.  To  develop  procedures  for  automating  the-  BEEQ  data  preparation 
and  database  maintenance  process,  using  the  integrated  data  files. 

8.  DESCRIPTION  OF  INVESTIGATION. 

a.  Summary.  The  formats  and  contents  of  several  standard  data¬ 
bases  will  be  reviewed.  Procedures  will  be  developed  for  comparing 
and  translating  data  files  from  these  databases  and  integrating  data 
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with  additional  information  required  for  battlefield  simulation,  and 
EMC/EMV  analysis.  These  procedures  will  be  implemented  in  data 
analysis  and  database  maintenance  software. 

b.  Detailed  Approach. 

(1)  The  U.S.  Army  TOE  and  Force  Modernization  database 
(VTAADS/VBOIP)  maintained  at  Fort  Leavenworth,  KS  for  HQDA  and  HQ 
TRADOC  will  be  compared  in  format  and  content  with  the  Army  equipment 
distribution  databases  (SB  700-20,  TAEDP )  maintained  at  Chambersburg, 

PA  for  HQDA  and  HQAHC . 

(2)  Similar  information  represented  by  different  databases 
will  be  identified.  Procedures  will  be  defined  for  identifying  and 
resolving  anomalies  and  discrepancies  between  data  files. 

(3)  Procedures  will  be  defined  for  integrating  existing  data 
into  a  single  data  file  with  additional  data  elements  defining  doctri¬ 
nal  battlefield  tactics  and  associations  between  military  units, 
vehicles,  personnel,  and  equipment. 

(4)  Procedures  will  be  implemented  in  a  set  of  computer  • 
programs  and  incorporated  in  the  BEEO  library  of  applications  software. 

c.  Final  Product (s). 

(1)  Documented  methodology  to  create  databases  for  battle¬ 
field  simulation  and  analysis  by  combining,  correlating,  and  supple¬ 
menting  standard  data  files  from  Army-standard  databases. 

(2)  Documented  computer  programs  implementing  the  methodology. 

Coordination.  This  investigation  will  require  coordination 
with  other  government  agencies  involved  in  the  development  of  battle¬ 
field  simulations  as  well  as  activities  maintaining  or  requiring 
databases  which  are  related  to  the  battlefield  electromagnetic 
environment. 


e.  Environmental  Impact  Statement.  This  investigation  will  have 
no  adverse  affect  on  the  environment. 

f •  Health  Hazard  Statement.  This  investigation  will  present  no 
health  hazard  to  personnel. 

9.  JUSTIFICATION. 

a*  Association  with  Mission.  This  MIP  directly  supports  the 
USAEPG  mission  to  perform  development  tests  of  C-E  equipment.  The 
capability  is  required  to  enable  the  USAEPG/BEEO  to  perform  its 
mission  of  support  to  development  testing,  Army  Force  Modernization 
and  Army  Spectrum  Management  as  defined  in  AR  5-12  in  a  timely  manner 
at  reasonable  cost.  It  will  be  used  to  provide  fundamental  input  data 
for  every  project  utilizing  the  EMETF  analysis  capability  and  to 
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provide  data  for  force  modernization  and  doctrinal  analysis  projects 
throughout  the  Army. 

b.  Association  with  Methodology/Ir.strumentation  Program.  This 
project  supports  a  priority  thrust  of  the  "ECOM  Methodology  Program  in 
that  it  will  eliminate  a  serious  existing  deficiency  in  test 
capabilities . 

c .  Present  Capability,  Limitations,  Improvement  and  Impact  on 
Testing  if  Not  Approved.  The  BEEO  has  been  using  manual  procedures 
for  analyzing  and  entering  data.  These  procedures  are  cumbersome, 
repetitive,  and  prone  to  errors.  Data  coding  sheets  and  database 
contents  must  be  continually  reviewed  for  interpretation  and  tran¬ 
scription  errors.  The  BEEO's  productivity  and  database  accuracy  is 
severely  limited  by  this  process.  Large  databases  necessary  for 
large-scale  (corps-sized  or  larger)  battlefield  simulations  now 
require  from  six  months  to  one  year  to  complete.  Analysis  projects 
requiring  these  large  battlefield  simulations  are  utilizing  data  which 
may  not  accurately  represent  current  doctrine  and  tactics.  Reductions 
in  the  scope  of  the  simulated  battlefield  to  division-size  or  less  so 
that  the  supporting  databases  will  have  reasonably  current  data  can 
result  in  an  incomplete  or  misleading  analysis. 

d.  Dollar  Savings.  C3I  analysis  will  be  more  complete  and 
accurate  which  will  lead  directly  to  better  decision-making  on  C3I 
programs.  It  will  allow  better  tradeoff  analyses  for  cost/benefit  and 
force  management  studies. 

e.  Workload.  BEEO  database  products  will  be  used  for  all  El EM 
analysis  efforts,  and  for  test  design  planning  and  force  Modernization 
studies.  Every  electromagnetic-dependent  system  is  required  to  be 
analyzed  by  the  EMETF. 

Examples  of  items  anticipated  for  testing  utilizing.  BEEO  data 
include : 


FY87 

FY88 

FY89 

MSE 

X 

X 

X 

PJH 

X 

X 

X 

GPS 

X 

HF  IMPROVEMENT 

X 

X 

X 

f .  Association  with  Requirements  Documents.  AR  5-12 


10.  RESOURCES. 


a.  Financial. 


Dollars  (Thousands) 
FY87 


In-House  Out-of-House 
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Personnel 

Compensation 


Travel 


Contractual 

Support 


80.0 


Subtotals  20.0 


80.0 


FY  Total 


100.0 


b.  Explanation  of  Cost  Categories. 


(1)  Personnel  Compensation.  For  in-house  personnel  costs. 


(2)  Travel.  Fort  Huachuca,  Arizona  to  Washington,  D.C. 


(3)  Contractual  Support.  Major  portion  of  investigation  will 
be  performed  under  contract. 


Obligation  Plan  (FY87) 


Obligation  Rate 
(Thousands ) 


12  3  4 

25.0  25.0  25.0  25.0 


TOTAL 

100.0 


d.  In-House  Personnel. 


In-House  Personnel  Recruirements  by  Specialty. 


Manhours 


FY87 


Systems  Analyst 
Tactician 


Number 

1 

1 


Required 

450 

300 

750 


Available 

450 

300 

750 


Total 

Required 

450 

300 

750 


11.  INVESTIGATION  SCHEDULE. 
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In-House 


Contract 


DEPARTMENT  OF  THE  ARMY 
HEADQUARTERS,  U  S.  ARMY  TEST  AND  EVALUATION  COMMAND 
ABERDEEN  PROVING  GROUND.  MARYLAND  21006  -6066 


A  J 


SUBJECT:  FY87  RDTE  Methodology  Improvement  Program  Directive 


Commander 

U.S.  Army  Electronic  Proving  Ground 

ATTN:  STEEP- TM- TO 

Fort  Huaehuca,  AZ  85613-7110 


1.  Reference  TECOM  Regulation  70-12,  dated  29  May  1985,  subject:  TECOM 
Methodology  Investigations. 

2.  This  letter  constitutes  a  directive  for  the  investigations  listed  in 
enclosure  1  under  the  TECOM  Methodology  Improvement  Program  1U665702D625. 

3.  The  MIPs  at  enclosure  2  are  the  basis  for  headquarters  approval  of  the 
investigations. 

Special  instructions: 

a.  All  reporting  will  be  in  consonance  with  paragraph  9  of  the  reference. 
The  final  report  will  be  submitted  to  this  headquarters,  ATTN:  AMSTE-TC-M,  in 
consonance  with  Test  Event  570/580.  Each  project  shall  be  completed  in  FY87  as 
reflected  in  the  scheduling. 

b.  Recommendations  for  new  TOP'S  or  revisions  to  existing  TOP'S  will  be 
included  as  part  of  the  recommendation  section  of  the  final  report.  Final 
decision  on  the  scope  of  the  TOP  effort  will  be  made  by  this  headquarters  as 
part  of  the  report  approval  process. 

c.  The  addressee  will  determine  whether  any  classified  information  is 
involved,  and  will  assure  that  proper  security  measures  are  taken  when 
appropriate.  All  OPSEC  guidance  will  be  strictly  followed  during  this 
investigation. 

d.  Prior  to  test  execution,  the  test  activity  will  verify  that  no  safety 
or  potential  health  hazards  to  humans  participating  in  testing  exist.  If 
safety  or  health  hazards  do  exist,  the  test  activity  will  provide  a 
safety/health  hazards  assessment  statement  to  this  headquarters  prior  to  test 
initiation. 


AMSTE-TC-M 

SUBJECT:  FY87  RDTE  Methodology  Improvement  Program  Directive 
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e.  Environmental  documentation  for  support  tests  or  special  studies  is  the 
responsibility  of  the  test  activity  and  will  be  accomplished  prior  to 
initiation  of  the  investigation/study. 


f.  Upon  receipt  of  this  directive,  test  milestone  schedules  a3  established 
in  TRMS  II  data  base  will  be  reviewed  in  light  of  other  known  workload  and 
projected  available  resources.  If  rescheduling  is  necessary  and  the  sponsor 
nonconcurs,  a  letter  citing  particulars,  together  with  recommendations,  will  be 
forwarded  to  Commander,  U.S.  Army  Test  and  Evaluation  Command,  ATTN: 

AMSTE-TC-M,  with  an  information  copy  to  AMSTE-TE-0,  no  later  than  15  calendar 
days  from  the  date  of  this  letter.  Reschedules  concurred  in  by  the  sponsor  can 
be  entered  directly  along  with  a  properly  coded  narrative  by  your 
installation/test  activity. 


g.  All  work  shall  be  performed  such  that  energy  consumption  and 
conservation  are  considered  throughout  the  effort. 


S 


h.  The  HQ,  TECOM  POC’s  for  individual  investigations  are  listed  in 
enclosure  1,  AMSTE-TC-M,  AUTOVON  298-2170/3677- 


i.  FY87  RDTE  funds  authorized  for  the  investigations  are  listed  on 
enclosure  1.  DARCOM  Form  1006  -will  be  forwarded  by  the  TECOM  Resource 
Management  Directorate.  A  cost  estimate  shall  be  submitted  within  30  days 
following  receipt  of  this  directive. 
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FOR  THE  COMMANDER: 


2  Ends 
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.GROVER  H 


^ _  SHELTON 

^  Chief,  Methodology  Improvement 
Division 

Directorate  for  Technology 
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AMC 

& 

BEEO 

CEOPS 

A 

y. 

COMSEC 

DBMS 

V, 

V 

K  * 

DGS 

£ 

EMC 

EMETF 

\K 

EMV 

V 

•o 

GOES 

N’'. 

GUES 

i 

GUF 

JETDS 

■  » 

$ 

LIN 

a 

ORA 

!r 

JL* 

RF 

STD 

•  * 

TECOM 

!*;• 

TRADOC 

USAEPG 

*  * 

VAX 

V 

V 

Hi* 

VBOIP 

VMS 

Army  Materiel  Command 

Battlefield  Electromagnetic  Environments  Office 

Communication-Electronic  Operator  Positioning  System 

Communications  Security 

Data  Base  Management  System 

Deployment  Generation  System 

Electromagnetic  Compatibility 

Electromagnetic  Environmental  Test  Facility 

Electromagnetic  Vulnerability 

Generic  Data  Entry  System 

Generic  Unit  Entry  System 

Generic  Unit  File 

Joint  Electronic  Type  Designation  System 
Line  Item  Number 

Organizational  Relationship  Application 
Radio  Frequency 
Simulated  Tactical  Deployment 
U.S.  Army  Test  and  Evaluation  Command 
U.S.  Army  Training  and  Doctrine  Command 
U.S.  Army  Electronic  Proving  Ground 
Virtual  Address  Extension 
Vertical,  Basis  of  Issue  Plan 
Virtual  Memory  System 

Vertical,  The  Army  Approved  Data  System 
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1.  SCOPE 

1.1  Identification 


This  Software  Requirements  Specification  (SRS)  establishes 
the  requirements  for  the  Computer  Software  Configuration  Item 
(CSCI)  identified  as  the  Generic  Data  Base  System  (GDBS) ,  CSCI 
C005T004D7 ,  of  the  Command,  Control,  Communications  and  Intelli¬ 
gence  (C3I)Data  Base  Division,  US  Army  Electronic  Proving  Ground 
(USAEPG) . 


1.2  Purpose 


This  CSCI  is  required  to  accomplish  timely  production  of 
data  files  which  precisely  record  doctrinal  associations  between 
personnel  and  equipment  in  generic  military  units.  These  data 
files  are  required  for  communication-electronic  simulation  and 
other  battlefield  electromagnetic  environment  analysis  activi¬ 
ties.  A  principal  user  of  these  data  files  is  the  Performance 
Analysis  of  Communication-Electronics  Systems  (PACES)  of  the 
USAEPG . 


The  data  files  characterize  a  stressed  electromagnetic  en¬ 
vironment.  The  radio  frequency  (RF)  equipment  of  interest  in¬ 
clude  communications  radios,  electronic  warfare/electronic  intel¬ 
ligence  devices,  radio  navigation  devices,  radar  devices,  tele¬ 
metry  equipment  and  remote  control/  sensor  devices.  Non-RF  ex¬ 
tensions  of  RF  communications  nets  may  be  represented  by  the  use 
of  pseudo-radios.  (e.g.  switchboards,  telephones) 


RF  equipment  of  interest  is  related  by  being  in  the  same 
net.  "Net”  usually  refers  to  a  radio  communication  net,  but  may 
refer  to  any  time  two  items  share  a  common  frequency  or  form  a 
communications  path. 


The  major  functions  of  the  GDBS  are  intelligent  data  entry, 
help  functions,  generic  unit  database  management,  integrity  en¬ 
forcement,  and  dataset  synthesis.  GDBS  is  a  data  entry  system 
coupled  to  a  data  base  management  system,,  with  a  limited  capabil¬ 
ity  for  automatic  dataset  generation. 


The  GDBS  replaces  the  coding  sheets  formerly  used  by  mili¬ 
tary  analysts  and  the  accompanying  rote  data  entry  function,  and 
it  advances  the  time  of  error  detection  to  an  earlier  point  in 
the  data  processing  flow.  In  addition,  it  provides  a  vehicle  for 
executing  the  partially  automated  generic  unit  file  building 
schemes . 
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1.3  Introduction 

This  document  specifies,  for  the  GDBS ,  all  applicable  func¬ 
tional,  interface,  performance,  and  qualification  requirements, 
including  the  requirements  for  programming  design,  adaptation  and 
quality  factors.  Traceability  requirements  are  not  included. 

2.  APPLICABLE  DOCUMENTS 

The  following  documents  of  the  exact  issue  shown  form  a  part 
of  this  specification  to  the  extent  specified  herein.  In  the 
event  of  conflict  between  the  documents  referenced  herein  and  the 
contents  of  this  specification,  the  contents  of  this  specifica¬ 
tion  shall  be  considered  superseding  requirements. 

2 . 1  Government  Documents 

DoD-STD-2 167  Defense  System  Software  Development 

2 . 2  Non-Government  Documents 

The  following  documents  may  be  obtained  from  the  Contracting 
Officer's  Representative  of  the  EMETF,  STEEP-DT-S,  Fort  Huachuca, 
Arizona  85613-7110: 


BTO  86-11-004 

BTO  87-02-010 
BTO  86-04-002 

BTO  87-02-003 

BTO  87-04-008 


Time  and  Labor  Estimate,  MIP  Generic  Unit 
Entry,  Revised  14  November  1986 

CEOPS  Data  Base  Files,  Revised  21  July  1987 

Description  of  the  CEOPS  Programs,  Revised 
6  August  1987 

DBDD  for  the  Generic  Data  Entry  System,  Re¬ 
vised  6  August  1987 

Software  Requirements  Specification  for  the 
Generic  TOE  Reports,  Revised  30  April  1987 


The  following  documents  may  be  obtained  from  Digital  Equip¬ 
ment  Corporation,  110  Spit  Brook  Road,  Nashua,  NH  03062-2698: 


AA-Y510B-TE 
AA-H485D-TE 
AA-L369B-TE 
AA-D034D-TE 
AA-D035D-TE 
AI-Y503  B-TE 


Guide  to  VAX/VMS  System  Security 
VAX  PASCAL  User's  Guide 
Programming  in  VAX  PASCAL 
Programming  in  VAX  FORTRAN 
VAX  FORTRAN  User's  Guide 

Guide  to  programming  on  VAX/VMS  (FORTRAN  Edi¬ 
tion) 
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The  following  documents  may  be  obtained  from  Relational 
Technology,  1080  Marina  Village  Parkway,  Alameda,  CA  94501-9891: 

INGRES/QUEL  REFERENCE  MANUAL 

INGRES/ FORMS :  . isual-Forms-Editor  User's  Guide 

INGRES/ EQUEL/ PAS CAL  USER'S  GUIDE 
INGRES/EQUEL/FORTRAN  USER'S  GUIDE 


The  requirements  for  the  CSCI  are  not  established  by  any 
written  documents.  The  requirements  specified  herein  are  derived 
from  the  known  characteristics  of  certain  prototype  computer 
programs . 


3.1.1 


This  CSCI  will  be  written  in  VAX  FORTRAN  77  and  VAX  Pascal 
with  embedded  QUEL  statements.  QUEL,  the  query  language  of  the 
INGRES  Database  Management  System,  will  be  used  to  program  all 
data  base  access  and  will  also  be  used  to  program  man/machine 
interface  functions.  The  INGRES  Visual  Forms  Editor  (VI FRED)  will 
be  used  to  develop  menus  and  forms  display  interactions.  Em¬ 
bedded  QUEL  statements  are  referred  to  as  "EQUEL"  statements. 

3.1.2  Comoiler/Assembler 

Although  VAX  Macro  assembly  language  is  used  during  the 
software  development,  it  will  not  be  used  for  programming.  The 
assembly  language  source  code  will  be  automatically  produced  by 
VI FRED.  No  person  will  edit  or  input  assembly  language  source 
files. 

Except  as  described  in  the  paragraph  above,  use  of  assembly 
language  is  neither  anticipated  nor  desired. 


The  source  code  shall  conform  to  the  design  and  coding 
standards  set  forth  in  Appendix  C  of  DoD-STD-2167 . 

Where  source  code  contains  embedded  QUEL  statements,  the 
standard  shall  apply  to  the  source  code  input  to  the  EQUEL  pre¬ 
processor  rather  than  to  the  text  files  output  by  the  EQUEL  pre¬ 
processor. 
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Data  retrieval  operations  and  man/ machine  interface. func¬ 
tions  will  be  programmed  by  control  constructs  which  simulate  the 
control  action  of  interrupt  service  routines.  In  other  words, 
there  will  be  a  block  of  code  which  is  executed  once  for  each  re¬ 
cord  which  is  returned  in  a  retrieval.  Similarly,  there  will  be 
blocks  of  code  which  are  executed  before  a  form  is  displayed. 
These  are  executed  when  the  user  presses  a  function  key,  when  the 
user  moves  the  cursor  out  of  a  display  field,  and  after  the  form 
is  displayed.  These  constructs  are  defined  in  the  EQUEL/FORTRAN 
and  EQUEL/Pascal  user's  guides. 

Local  variables  which  are  allocated  from  the  stack  will  be 
prevented  from  being  used  in  other  units  by  the  rules  of  the  Pas¬ 
cal  compiler.  This  requires  that  all  variables  be  allocated  ir. 
the  procedure  using  them,  or  in  a  surrounding  procedure. 

All  units  of  this  CSCI,  including  all  main  programs,  subrou¬ 
tines,  functions  and  procedures,  are  the  responsibility  of  the 
C3I  Data  Base  Department  of  the  EMETF. 

A  formal  testing  and  problem  reporting  procedure  will  not  be 
instituted  prior  to  delivery  of  the  CSCI  because  of  the  close  as¬ 
sociation  between  users  and  developers. 

3.2  Design  Requirements 

The  design  requirements  are  stated  here  in  reference  to  the 
present  configuration  and  usage  of  the  Digital  Equipment  Corpora¬ 
tion  (DEC)  VAX-11/785  computer  at  the  Field  Engineering  Division, 
Data  Systems  Branch  of  the  US  Army  Electronic  Proving  Ground, 

Fort  Huachuca,  Arizona.  This  is  a  multiuser  system  supporting 
other  programs  not  related  to  this  CSCI. 
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3.2.1  Sizing  and  Timing  Requirements  .A  ; 

v,  ! 

The  GDBS  will  support  seven  concurrent  users  each  requiring  y 

less  than  four  megabytes  of  virtual  memory.  The  timing  require¬ 
ments  depend  on  the  mode  of  operation.  There  are  two  modes:  re-  'i?  \ 

cord  mode  and  dataset  mode.  In  record  mode,  this  CSCI  will  use 
less  than  25%  of  the  computers'  total  Central  Processing  Unit 
(CPU)  processing  time  per  user,  with  the  user  waiting  time  aver- 
aged  over  the  user's  entire  session  to  be  less  than  45  seconds.  ^ 

In  dataset  mode,  the  CSCI  will  use  less  than  50%  of  the  CPU  with  , 

the  average  waiting  time  required  to  process  one  unit  less  than  „  • 

90  seconds.  )■>  \ 

; 

3.2.2  Design  Standards  ' 


This  CSCI  will  be  designed  in  compliance  with  the  require- 
;  ments  of  DoD-STD-2167 . 
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3.2.3  Design  Constraints 

This  CSCI  will  be  designed  to  run  on  the  DEC  VAX-11/785  at 
the  Field  Engineering  Division,  Data  Systems  Branch  of  the  US 
Army  Electronic  Proving  Ground,  Fort  Huachuca,  Arizona.  Use  of 
mass  storage  and  peripheral  devices  will  be  conr stent  with  pre¬ 
sent  configuration  of  that  machine. 

The  INGRES  Data  Base  Management  System  and  the  VAX/Virtual 
Memory  System  (VMS)  operating  system  will  be  used.  This  implies 
that  the  man/machine  interface  will  be  implemented  using  the 
INGRES  VI FRED. 

This  CSCI  must  satisfy  the  following  conventions:  Every  RF 
item  of  interest  shall  be  treated  as  a  communications  radio  car¬ 
ried  on  a  vehicle  connected  to  an  antenna  and  operated  by  an  op¬ 
erator.  Every  net  will  be  controlled  by  an  operator  and  equip¬ 
ment  item  which  comprise  the  Net  Control  Station  (NCS) .  Pseudo¬ 
radios,  pseudo-antennas,  pseudo-vehicles  and  pseudo-NCS's  will  be 
created  whenever  these  conventions  would  otherwise  be  violated. 

3 . 3  Interface  Reouirements 


This  paragraph  specifies  the  user  interfaces,  report  output, 
interface,  Communications-Electronics  Operator  Positioning  System 
(CEOPS)  compatibility  interface,  and  super-user  interface  to  the 
CSCI.  The  data  base  server  interface  is  managed  by  the  EQUEL 
preprocessor  and  the  data  base  server.  Therefore,  these  inter¬ 
faces,  which  are  transparent  to  both  the  CSCI  developers  and  the 
CSCI  users,  are  not  specified  here.  The  character  data  communi¬ 
cation  interface  of  this  CSCI  to  the  terminal,  with  the  exception 
of  function  key  mapping,  is  managed  transparently  by  the  VAX/VMS 
operating  system  and  is  not  specified  here. 

3.3.1  Interface  Relationship 


The  GDBS  will  have  interfaces  to  the  terminals,  to  report 
printers,  and  to  the  tape  drive. 

3.3.2  Interface  Identification  and  Documentation 
None. 

3.3.3  Detailed  Interface  Requirements 

3. 3. 3.1  CSCI-to-CSCI  Interface  Requirements 


One  CSCI  with  which  the  GDBS  interfaces,  CEOPS  (an  EMETF 
Cyber  180-830  set  of  programs) ,  is  documented  in  "CEOPS  Data  Base 
Files".  The  other  CSCI,  Generic  TOE  Reports  (also  run  on  the 
EMETF  Cyber),  is  documented  in  "SRS  for  the  Generic  TOE  Reports". 
The  data  base  transactions  are  described  in  the  "INGRES/QUEL 
Reference  Manual". 
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Data  output  for  the  CEOPS  and  TOE  Report  CSCIs  of  the  EMETF 
Cyber  computer  will  be  transferred  via  magnetic  tape  in  ASCII 
format,  80  character  fixed  length  records.  The  record  contents 
and  format  are  specified  in  "CEOPS  Data  Base  Files" . 

3. 3. 3. 2  CSCI-to-HWCI  or  Critical  Item  Requirements 

No  interfaces  to  hardware  other  than  those  managed  by  the 
VAX/VMS  Operating  System  are  anticipated. 

3 . 4  Detailed  Functional  and  Performance  Requirements 

As  stated  in  paragraph  1.2,  the  major  functions  of  the  GDBS 
are  intelligent  data  entry,  help  functions,  generic  unit  database 
management,  integrity  enforcement,  and  dataset  synthesis.  The 
CSCI  will  operate  in  three  modes:  record  mode,  dataset  mode,  and 
direct  mode.  The  three  modes  each  use  a  different  subset  of  the 
total  CSCI  functions.  Record  mode  is  usually  called  the  Generic 
Data  Entry  System  (GDES) .  Dataset  mode  is  usually  called  the 
Generic  Unit  Entry  System  (GUES) .  Direct  mode  can  be  either 
INGRES  (INGRES  subsystems)  or  GDES  (run  all  users) .  In  direct 
mode,  all  CSCI  functions  defined  by  the  INGRES  documentation  set, 
which  are  applicable  to  the  data  base  are  provided.  Only  the 
super-user (s)  are  given  privilege  to  use  the  direct  mode.  (See 
paragraph  3. 4. 3. 6  for  a  description  of  "super-user".) 

3.4.1  Intelligent  Data  Entry  Function 

These  functions  include  validation  of  fields,  inheritance  of 
previous  values  for  fields,  mandatory  fields,  and  field  combin¬ 
ation  on  record  checking.  This  function  will  be  active  when  GDBS 
is  operating  in  record  mode  (GDES)  and  a  record  is  modified  or  a 
new  record  is  added.  Intelligent  data  entry  function  will  be  ap¬ 
plied  by  making  a  data  entry  field  on  a  visual  form  for  every  ap¬ 
plicable  field  of  the  data  records  created  by  the  GDBS. 

3.4. 1.1  Validation  of  Fields  Function 


The  validation  of  fields  function  checks  values  entered 
against  legal  value  ranges  and  legal  value  lists. 

3. 4. 1.1.1  Field  Validation  Inputs 

The  user  input  at  the  keyboard  will  be  compared  with  legal 
value  lists  in  the  codebook  files,  which  are  defined  in  the  "DBDD 
for  the  Generic  Data  Entry  System".  Legal  value  constraint  for¬ 
mulas  will  be  taken  from  the  forms  produced  by  the  INGRES  subsys¬ 
tem  VI FRED. 

3. 4. 1.1. 2  Field  Validation  Processing 

The  data  entered  will  be  checked  for  range  and  against  the 
legal  value  list. 
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Valid  data  will  be  displayed  on  the  screen  as  it  is  accept¬ 
ed.  Invalid  data  will  cause  plain  English  error  messages  and/or 
a  beep  (bell)  at  the  terminal. 

3. 4. 1.2  Mandatory  Fields  Function 

Mandatory  fields  are  fields  which  must  have  a  value  entered 
before  the  user  can  append  a  new  record  to  the  data  base. 

3. 4. 1.2.1  Mandatory  Field  Inputs 

Mandatory  fields  will  be  identified  by  the  attribute  manda¬ 
tory  on  the  data  entry  visual  form  attribute  edit  form.  The  user 
will  usually  acknowledge  an  error  message  with  a  carriage  return. 

3 . 4 . 1 . 2 .2  Mandatory  Field  Processing 

Whenever  a  visual  form  is  displayed  and  a  mandatory  field  is 
absent,  the  session  will  be  suspended  until  the  user  acknowledges 
the  error  and/or  corrects  it. 

3. 4. 1.2. 3  Mandatory  Field  Outputs 

If  the  field  is  blank  or  in  error  then  an  error  message  will 
be  output  to  the  screen.  Otherwise,  the  field  entry  is  accepted. 

3.4. 1.3  Field  Combination  on  Record  Checking  Function 

This  function  will  check  for  legal  combinations  of  field 
values  on  each  record  before  the  record  is  appended  to  the  data 
base. 


3. 4. 1.3.1  Record  Checking  Inputs 

The  record  entered  by  the  user  will  be  checked  against  the 
records  of  the  legal  combination  reference  file. 

3. 4. 1.3. 2  Record  Checking  Processing 

A  search  will  be  performed  for  a  record  in  the  legal  combi¬ 
nation  reference  file.  If  the  search  fails,  an  error  message 
will  be  output  and  the  new  record  will  be  rejected. 
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3. 4. 1.3. 3  Record  Checking  Output 


Output  will  consist  of  an  error  message. 

3.4.2  Help  Function 

The  help  function  provides  scrollable  text  information  to 
the  user,  on  demand,  tailored  to  the  user's  current  step  in  the 
data  entry  operation.  The  help  functions  are  active  in  the  re¬ 
cord  ( GOES )  mode . 

3.4.2. 1  Help  Function  Inputs 

The  user  invokes  the  help  function  via  a  single  function 
key.  The  help  text  comes  from  a  text  file  which  may  be  edited  by 
the  super-user. 

3. 4. 2. 2  Help  Function  Processing 

The  text  may  be  scrolled  a  line  or  page  at  a  time  on  the 
terminal  until  the  user  presses  'END'.  Then  the  screen  will  be 
restored  to  its  previous  display. 

3. 4. 2. 3  Help  Function  Outputs 


The  help  text  is  displayed  on  the  screen. 


3.4.3 


These  functions  include  report  generation,  concurrency  con¬ 
trol,  user  access  control,  record  validity  and  record  integrity 
checking. 

3. 4. 3.1  Report  Generation  Function 

This  function  will  provide  generic  unit  summary  reports. 

3. 4. 3. 1.1  Report  Generation  Inputs 

The  user  will  produce  reports  on  demand  by  selecting  the 
PRINT  function  from  the  menu  while  the  table  of  Standard  Require¬ 
ments  Code  (SRC)  numbers  are  displayed.  The  SRC  number  marked  by 
the  cursor  location  will  identify  the  generic  unit  to  be  printed. 
All  records  for  that  unit  will  be  reported.  After  the  first  pro¬ 
cessing  phase,  the  user  will  enter  a  number  for  the  number  of 
copies  of  the  report  to  be  printed. 

3. 4. 3. 1.2  Report  Generation  Processing 

For  each  net,  the  data  pertaining  to  that  net  is  collected 
and  associated  with  the  data  pertaining  to  RF  equipment  of  inter¬ 
est  in  that  net.  The  data  is  sorted  by  the  Operator  ID  and  Oper¬ 
ator  Number  of  the  operators  in  that  net.  The  report  is  format¬ 
ted  and  sent  to  the  printer  one  or  more  times. 

3. 4.3. 1.3  Report  Generation  Outputs 
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The  report  output  will  consist  of  line  printer  pages  con¬ 
taining  the  net  data  and  equipment  data,  broken  down  by  net,  with 
one  line  of  data  for  each  component  of  each  item  of  equipment  in 
the  net.  The  data  line  will  include  data  about  the  vehicle  and 
operator  associated  with  that  item  of  equipment.  The  report  gen¬ 
eration  function  will  be  available  when  the  CSC I  is  operating  in 
record  (GDES)  mode. 

3. 4. 3. 2  Concurrency  Control  Function 


The  concurrency  control  function  sequences  and  synchronizes 
user  access  to  the  data  base. 

3. 4. 3. 2.1  Concurrency  Control  Inputs 


None. 


3. 4. 3. 2. 2 


Concurrency  control  will  take  place  when  two  users  are  dead¬ 
locked  according  to  the  logical  record  blocking  internal  to  the 
data  base.  The  action  will  cause  the  second  user  to  wait  for  the 
completion  of  the  first  user's  update. 

3. 4. 3. 2. 3  Concurrency  Control  Outputs 
None. 

3.4. 3. 3  User  Access  Control  Function 

The  user  access  control  function  will  discriminate  between 
user  and  super-user,  will  challenge  and  identify  all  users,  and 
will  protect  each  user's  data  from  any  access  by  other  users. 

This  is  a  record  mode  (GDES)  function. 

3. 4. 3. 3.1  User  Access  Control  Inputs 

Each  user  will  enter  their  user  ID  and  password  at  log-in 
time.  The  super-user  will  have  built  and  maintained  a  list  of 
user  ID's  and  user/ super-user  flags  prior  to  the  particular 
user's  log-in  time.  The  supervisor  may  also  enter  any  user's  ID 
with  an  SRC  number. 
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3. 4. 3. 3. 2  User  Access  Control  Processing 

The  CSCI  will  automatically  maintain  an  ownership  relation 
between  users  and  generic  units,  and  will  allow  the  super-user  to 
transfer  ownership. 

User  access  control  processing  will  occur  at  startup  time 
immediately  after  log-in,  at  the  time  the  first  SRC  Header  Record 
associated  with  a  particular  generic  unit  is  appended  to  the  data 
base,  and  anytime  the  records  of  a  generic  unit  are  transferred 
to  another  user.  The  actions  will  be  as  follows:  At  startup 
time  the  generic  unit(s)  whose  most  recent  access  was  done  by  the 
user  will  be  selected.  The  user  will  be  granted  access  to  these 
units.  At  the  time  an  SRC  Header  Record  is  appended  to  the  data 
base,  the  user's  ID  will  be  recorded  and  associated  with  that 
unit.  At  transfer  time,  the  user  ID  entered  by  the  super-user 
will  replace  the  user  ID  associated  with  the  unit.  A  user  will 
be  required  to  exit  and  re-enter  the  record  mode  (GDES)  to  gain 
access  to  units  reassigned  after  entry. 

3. 4. 3. 3. 3  User  Access  Control  Outputs 

The  user  ID  of  the  owner  of  each  generic  unit  will  be  dis¬ 
played  to  the  super-user  at  startup  time. 

3. 4. 3. 4  Transaction  Commitment  Function 

The  transaction  commitment  function  will  manage  situations 
where  the  data  entered  for  each  field  of  a  record  is  valid,  but 
the  combination  of  values  in  the  record  is  invalid.  It  will  pre¬ 
vent  the  invalid  record  from  being  appended  to  the  data  base. 


3. 4. 3. 4.1 


ansaction  Commitment  Inputs 


This  function  maintains  a  record  in  a  state  of  suspense 
until  the  record  is  validated.  It  will  discard  the  record  if  it 
is  invalid.  Otherwise,  the  record  is  appended  to  the  data  base. 

3 . 4 . 3 . 4 . 3  Transaction  Commitment  Outputs 


When  the  user  attempts  to  add  an  invalid  record  to  the  data 
base  an  error  message  will  be  displayed.  The  data  fields  will 
not  be  cleared,  and  the  user  will  be  given  an  opportunity  to  cor¬ 
rect  the  record. 
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3. 4. 3. 5  Security  Control  Functioi 


fRecord  Mode) 


This  function  supports  the  labeling  and  access  restriction 
of  secret  data.  Records  in  the  data  files  will  possess  unique 
security  level  attributes.  However,  those  records  in  the  net 
header,  operator,  and  vehicle  tables  will  possess  a  single  secur¬ 
ity  level  for  all  records  pertaining  to  a  single  generic  unit. 
(See  below  and  also  see  paragraph  3.6.4.) 

3. 4. 3. 5.1  Security  Control  Inputs  fRecord  Mode) 

The  maximum  security  level  is  obtained  from  the  existing 
generic  units  owned  by  the  user. 

The  security  level  of  a  generic  unit  will  be  input  by  the 
Military  Analyst  at  the  time  the  SRC  Header  Record  data  is  en¬ 
tered.  The  security  level  of  all  data  associated  with  that  gene¬ 
ric  unit,  as  indicated  by  the  SRC  Number,  will  be  inherited  from 
the  security  level  of  the  generic  unit.  There  will  be  three  sec¬ 
urity  levels:  0  =  unclassified;  1  =  confidential;  2  =  secret. 

The  system  will  not  allow  downgrading  the  classification  of  a 
unit  if  there  are  codes  of  higher  classification  contained  in  any 
of  the  records. 

3. 4. 3. 5. 2  Security  Cpntr9l...,Pr9g?ssi,n.q_(Recoyd  Mode) 

The  highest  security  level  of  all  generic  units  belonging  to 
the  Military  Analyst  will  be  selected  as  the  maximum  level. 

Certain  functions  of  the  CSCI  cause  data  to  be  extracted 
from  the  codebook  tables  and  joined  to  data  in  the  operator  and 
vehicle  tables.  The  results  will  be  output  to  reports  and  dis¬ 
played  to  the  military  analyst  at  his  workstation.  The  security 
control  function  will  restrict  retrieval  of  classified  codebook 
nomenclature  by  not  processing  or  displaying  nomenclature  data 
whose  classification  is  higher  than  the  classification  of  the 
current  generic  unit. 


3. 4. 3. 5. 3  Securi 


Control  Outputs  fRecord  Model 


The  highest  security  level  will  be  displayed  to  the  Military 
Analyst  when  the  SRC  Header  Records  (generic  units)  are 
displayed.  At  other  times,  the  security  level  of  the  current  ge¬ 
neric  unit  will  be  displayed.  This  level  is  also  included  on 
printed  reports. 

3. 4. 3. 6  Security  Control  (Direct  Mode) 

Only  the  Data  Base  Administrator/super-user  will  have  access 
to  the  direct  mode.  The  super-user  has  privileges  above  the  cus¬ 
tomary  users.  The  super-user  functions  within  the  group  in  a 
fashion  similar  to  the  System  Manager's  function  within  the  total 
system.  There  are  no  explicit  security  control  inputs, 
processes,  or  outputs  in  direct  mode. 

3. 4. 3. 7  Security  Control  (Dataset  Mode) 


I 

i 


SRS  -  C005T004D7 


In  dataset  mode  (GUES) ,  classified  data  will  not  be 
accessed.  All  data  added  will  be  given  a  security  code  of  "0" 
(unclassified).  There  are  no  explicit  security  control  inputs, 
processes,  or  outputs  in  the  dataset  mode. 

3.4.4  Data  Base  Integrity  Constraint  Functions 

Integrity  constraint  functions  will  be  active  in  both  the 
record  (GOES)  and  dataset  (GUES)  modes.  These  functions  will  as¬ 
sure  the  correct  relationships  between  records  so  that  the  data 
base  information  will  be  consistent  and  meaningful.  Integrity 
constraints  include  parent-child  relationship  enforcement,  allo¬ 
cation  relationship  enforcement,  compatibility  relationship  en¬ 
forcement,  and  completeness  enforcement.  These  functions  will  be 
supported  by  constraint  file  maintenance,  which  is  done  in  direct 
mode.  The  other  integrity  functions  are  not  available  in  direct 
mode.  The  integrity  (sub)  functions  work  differently  in  the  dif¬ 
ferent  modes,  so  they  will  be  documented  here  as  distinct  func¬ 
tions  . 

3. 4. 4.1  Parent-Child  Constraint  Function  (Record  Mode) 

The  GDES  user  will  be  presented  with  the  option  of  creating 
a  net  only  after  he  has  selected  or  created  a  generic  unit. 
Likewise,  he  will  have  the  option  of  creating  an  operator  only 
after  he  has  created  a  net. 

3.4.4. 1.1  Parent-Child  Constraint  Inputs 

None.  Constraint  is  accomplished  by  forcing  the  sequence  of 
events  as  described  in  paragraph  3 . 4 . 4 . 1 . 

3. 4. 4. 1.2  Parent-Child  Constraint  Processing 


None. 


3.4.4. 1.3  Parent-Child  Constraint  Outputs 


None. 


3. 4. 4. 2  Allocation  Constra: 


Function  (Record  Model 


The  GDES  user  will  be  prevented  from  putting  the  same  opera¬ 
tor  on  two  vehicles,  or  c  daring  two  net  control  stations  for 
the  same  net.  Operators  placed  on  the  same  vehicle  as  one  ano¬ 
ther  will  remain  on  the  same  vehicle  even  when  vehicle  data  is 
modified. 
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2.1  Allocation  Constraint  Function  Incuts  (Record  Mode 


The  entry  of  an  Operator  ID  and  Operator  Number  will  be  an 
input  for  vehicle  allocation.  The  vehicle  code  and  sequence  num¬ 
ber  are  also  inputs.  The  NCS  code  entry  will  be  an  input  for  net 
v  octroi  station  allocation.  These  data  entries  correspond  to  key 
fields  in  the  data  base  tables. 

3. 4. 4. 2. 2  Allocation  Constraint  Function  Processin 


When  the  operator  ID  and  number  are  entered,  the  CSCI  will 
search  for  associated  vehicle  information.  If  found,  the  opera¬ 
tor  record  will  receive  that  vehicle  information.  When  vehicle 
data  is  modified,  the  CSCI  searches  for  and  modifies  data  for  all 
operators  on  that  vehicle.  When  an  NCS  code  is  entered,  if  the 
NCS  code  identifies  that  operator  with  the  net  control  station, 
then  the  CSCI  will  search  for  a  previously  declared  NCS  operator. 


3. 4. 4. 2. 3 


?cation  Constraint  Function  Outputs 


In  the  event  of  a  re-declared  net  control  station,  an  error 
message  will  be  output  to  the  terminal.  Vehicle  data  modifica¬ 
tions  will  act  on  the  vehicle  data  table  and  will  cause  an  advi¬ 
sory  message  to  be  displayed. 


The  CSCI  will  reject  incompatible  combinations  of  RF  equip 
ment,  component,  antenna,  and  vehicle. 


The  major  equipment  code,  component  code,  antenna  code,  and 
vehicle  code  fields  of  the  data  entry  form  will  be  assembled  into 
a  reference  record. 

3. 4. 4. 3. 2  Compatibility  Relationship  Processing  (Record  Mode 


The  reference  record  (see  paragraph  3. 4. 4. 3.1)  is  searched 
for  in  the  compatibility  table. 


3. 4. 4. 3. 3 


tv  Relationship  Outputs  (Record  Mode 


tv  Relationsh 


The  GUES  user  will  supervise  the  selection  of  compatible 
vehicle/major  equipment  and  compatible  component/antenna  combina 
tions  from  two  compatibility  tables.  The  correct  major  equip¬ 
ment/component  combination  will  be  obtained  from  an  equipment  de 
finition  table. 
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3. 4. 4. 4.1  Compatibility  Relationship  Enforcement  Inputs  (Dataset 
Mode) 

The  selection  of  vehicle/equipment  will  come  from  the  appli¬ 
cation  of  a  rule,  which  may  imply  user  input.  The  selection  of  a 
compatible  antenna  will  come  from  user  input. 

3. 4. 4. 4. 2  Compatibility  Relationship  Enforcement  Processing 
(Dataset  Mode) 

None,  except  for  carrying  out  user  selection  and  retrieving 
definitions. 

3. 4. 4. 4. 3  Compatibility  Relationship  Enforcement  Outputs 
(Dataset  Mode) 

The  joined  vehicle,  equipment,  component  and  antenna  will  be 
output  to  the  table  of  operator  records. 

3. 4. 4. 5  Completeness  Enforcement  Function 

The  completeness  enforcement  function  will  assure  that  at 
least  one  record  will  be  created  for  every  component  part  of  an 
RF  item  of  interest,  and  that  the  correct  emitter/receiver  char¬ 
acteristic  code  will  be  attributed  to  that  component.  This  func¬ 
tion  will  be  available  in  dataset  (GUES)  mode  only. 

3. 4. 4. 5.1  Completeness  Enforcement  Function  Inputs 

The  completeness  enforcement  will  be  driven  by  tables  of 
equipment  and  component  definitions.  These  tables  are  identified 
as  EQP_DEF  and  COMP_DEF  in  the  "DBDD  for  the  Generic  Data  Entry 
System  Document" . 

3. 4. 4. 5. 2  Completeness  Enforcement  Function  Processing 

Using  the  equipment  code,  the  tables  EQP_DEF  and  COMP_DEF 
are  searched  to  find  the  applicable  data  elements  required  to 
complete  the  component  and  emitter  code  fields. 

3. 4. 4. 5. 3  Completeness  Enforcement  Function  Outputs 

The  component  code  and  emitter  code  fields  will  be  outputs. 

( See  also  paragraph  3 . 4 . 4 . 4 . 3 . ) 

3. 4. 4. 6  Constraint  File  Maintenance  Function 

The  super-user  will  be  able  to  append  to,  update,  retrieve 
from,  and  generate  reports  from  the  constraint  (compatibility) 
file.  This  function  will  be  active  only  when  the  CSCI  is  in  di¬ 
rect  mode. 
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3. 4. 4. 6.1  Constraint  File  Maintenance  Function  Inputs 

The  inputs  will  be  standard  QUEL  commands  and  INGRES  subsys¬ 
tem  commands. 

3. 4. 4. 6. 2  Constraint  File  Maintenance  Function  Processing 

The  processes  will  be  standard  QUEL  command  processes  and 
INGRES  subsystem  processes. 

3. 4. 4. 6. 3  Constraint  File  Maintenance  Outputs 

The  outputs  shall  consist  of  standard  INGRES  QUEL  retrieval, 
and  a  printed  report  of  the  constraint  file. 

3.4.5  Dataset  Synthesis  Function 


•jt  The  dataset  synthesis  function  searches  for  the  combinations 

,Vs  of  RF  equipment  items  of  interest  which  produce  the  most  stressed 

electromagnetic  environment,  subject  to  the  constraints  on  which 
.  equipment  may  be  placed  on  which  vehicles  and  which  equipment  may 

be  mounted  on  the  ground  or  carried  by  an  operator.  This  func- 
tion  will  only  be  active  in  dataset  (GUES)  mode. 
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3. 4. 5.1  Dataset  Synthesis  Function  Inputs 

The  dataset -synthesis  function  will  read  the  table  of  vehi¬ 
cle  configuration  constraints,  the  CONFIG_REF  and  C0NFIG_DEF 
files.  It  will  also  access  the  tables  of  organization  and  equip¬ 
ment  in  the  Vertical,  The  Army  Approved  Data  System  (VTAADS)  data 
files  and  respond  to  user  inputs.  The  dataset  synthesis  function 
will  accomplish  its  end  under  supervisory  control  of  the  Military 
Analyst.  Due  to  the  synthetic  nature  of  this  function,  it  may 
access  any  data  in  the  CSCI. 

3.4. 5. 2  Dataset  Synthesis  Function  Processing 

This  function  will  operate  as  a  production  system.  This 
means  that  there  will  be  a  processing  state,  a  set  of  production 
rules  and  a  termination  condition.  Repeatedly,  the  function  will 
examine  the  state,  select  applicable  production  rules,  determine 
the  highest  priority  rule  (with  user  input) ,  and  apply  that  rule 
to  update  the  state.  Processing  will  terminate  when  the  user  ei¬ 
ther  uses  all  the  RF  equipment  or  quits) . 

3. 4. 5. 3  Dataset  Synthesis  Function  Outputs 


This  function  outputs  partial  operator  records. 

3 . 5  Adaptation  Requirements 

The  CSCI  adaptation  data  includes  user  terminal  type,  code- 
*'  book  size  and  data  base  table  file  index  structures. 


3.5.1  System  Environment 
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The  system  environment  includes  terminal  types.  The  ter¬ 
minal  types  will  be  accommodated  by  the  use  of  Forms  Runtime  Sys¬ 
tem  Mapping  Files  which  are  described  in  the  INGRES  documenta¬ 
tion. 

Terminal  type  accommodation  data  will  be  used  by  the  man/ma¬ 
chine  user  interfaces  of  all  functions  of  the  CSCI. 


3.5.2  System 


neters 


The  system  parameters  include  codebook  size  limit  and  data 
base  optimization  statistics.  The  codebook  size  limit  is  set  by 
a  FORTRAN  parameter  statement,  is  used  by  the  field  validation 
function  and  applies  to  the  operator  code  field  of  the  operator 
records  only. 

The  data  base  optimization  statistics  data  will  be  collected 
when  the  data  base  administrator  gives  the  optimize  command,  and 
are  subsequently  applied  whenever  data  base  retrieval  occurs  from 
the  data  base  of  this  CSCI.  All  functions  which  retrieve  from 
the  data  base  are  effected. 

3.5.3  System  Capacities 

System  capacity  is  limited  by  the  system  hardware.  The  max- 
'imum  numbers  of  nets  per  generic  unit  and  operators  per  net  af¬ 
fects  the  parent-child  integrity  enforcement  function. 


3.6.1  Correctness 


lirements 


The  data  base  which  is  loaded  and  maintained  by  the  CSCI 
GDBS  shall  consistently  and  faithfully  represent  the  organiza¬ 
tional  characteristics  of  the  generic  units  as  defined  by  the 
Military  Analyst.  It  shall  characterize  maximal  use  of  RF  equip¬ 
ment  according  to  analyst  input  (dataset  mode) . 


3.6.2  Reliabilit-\ 


.irements 


The  CSCI  reliability  shall  be  considered  to  be  acceptable  if 
it  is  sufficient  to  allow  the  generic  unit  files  for  200  generic 
units  to  be  created  in  record  mode  without  failure  due  to  impro¬ 
perly  functioning  software.  For  dataset  mode,  the  requirement 
will  be  75  generic  units. 

3.6.3  Efficiency  Requirements 


The  CSCI  shall  be  designed  to  minimize  data  storage  and  ex¬ 
ecution  time. 
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3.6.4  Integrity 


lirements 


No  one  will  be  able  to  use  the  CSCI  without  a  valid  pass¬ 
word.  This  service  will  be  provided  by  the  operating  system  en¬ 
vironment  and  will  not  be  part  of  the  CSCI.  The  operating  system 
will  provide  user  names  also.  The  CSCI  will  maintain  a  table  of 
authorized  users  and  authorized  privileged  users  (super-users) . 
Unauthorized  persons  will  be  rejected.  Access  to  a  generic  unit 
will  be  allowed  only  to  the  user  who  currently  owns  the  unit  and 
to  privileged  users. 

3.6.5  Usability  Requirements 

A  Military  Analyst  with  no  computer  background  will  be  able 
to  use  this  CSCI  after  four  supervised  lessons.  This  applies  to 
usage  in  records  (GDES)  mode.  In  dataset  mode  (GUES) ,  famili¬ 
arity  with  vehicle  configurations  will  also  be  required.  To  use 
the  CSCI  in  direct  (INGRES)  mode,  fundamental  knowledge  of  QUEL, 
the  query  language,  and  relational  data  base  operations  and 
structures  shall  also  be  required. 

Interpretation  of  output  reports  shall  require  no  additional 
effort.  The  reports  will  be  similar  to  the  format  of  existing 
reports  produced  by  other  CSCI's. 

3.6.6  Maintainability  Requirements 

The  CSCI  shall  be  designed  in  a  modular  structure  with  each 
module  performing  a  single  well-defined  function.  The  mainte¬ 
nance  effort  shall  consist  of  identifying  the  module  associated 
with  the  function  in  question  and  locating  the  error  within  the 
module. 


3.6.7 


Not  specified. 


3.6.8 


None. 


3.6.9 


The  maximum  effort  required  to  transfer  the  implemented  CSCI 
to  a  DEC  MicroVAX  will  be  one  man  year.  The  ability  to  port  this 
system  to  any  other  has  not  been  estimated. 

3.6.10  Reusability  Requirements 

None. 
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3.6.11  Interoperability • Requirements 

The  output  data  shall  be  compatible  with  the  CEOPS  CSCI  of 
the  PACES  system. 

3.6.12  Additional  Quality  Factor  Requirements 


None. 


3 . 7  CSCI  Support 


To  be  determined.  Includes  facility  security. 


This  CSCI  is  traceable  to  TRMS  PROJECT  NO:  7-CO-R87-EPO-007 , 
Methodology  Investigation  Proposal  -  Generic  Unit  Entry. 


General  qualifications  shall  be  accomplished  by  demonstra¬ 
tion  and  inspection  of  data,  on  the  screens  and  in  printed  re- 


The  name  and  number  of  the  CSCI  to  be  delivered  are  the  GDBS 
CSCI  and  CSCI  C005T004D7  respectively.  The  media  for  delivery 
for  the  GDBS  CSCI  will  consist  of  executable  object  files  for  the 
GUES  and  GDES  resident  on  the  DEC  VAX  11/785. 
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6.  NOTES 

A  glossary  of  terms  used  in  this  specification  are  as  fol¬ 
lows: 

6 . 1  Abbreviations  and  Acronyms 

BTO  Bell  Technical  Operations 

C3I  Command,  Control,  Communications  and  Intelligence 

CEOPS  Communications-Electronics  Operator  Positioning 

System 

CM  Configuration  Management 

CPU  Central  Processing  Unit 

CRDL  Contract  Requirements  Data  List 

CSCI  Computer  Software  Configuration  Item 

DBDD  Data  Base  Design  Document 

DEC  Digital  Equipment  Corporation 

DoD  Department  of  Defense 

EMETF  Electromagnetic  Environmental  Test  Facility 

GDB  Generic  Data  Base 

GDBS  Generic  Data  Base  System 

GDES  Generic  Data  Entry  System 

GUES  Generic  User  Entry  System 

HWCI  Hardware  Configuration  Item 

MIP  Methodology  Investigation  Proposal 

NCS  Net  Control  station 

PACES  Performance  Analysis  for  Communication-Electronic 

Systems 

QA  Quality  Assurance 

RF  Radio  Frequency 

SRC  Standard  Requirements  Code 

SRS  System  Requirement  Specification 
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STD  Standard,  also  Standard  Tactical  Deployment 

TOE  Table  of  Organization  and  Equipment 

USAEPG  U.S.  Army  Electronic  Proving  Ground 


VTAADS 


Virtual  Memory  System 

VERTICAL,  The  Army  Approved  Data  System 
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DATA  BASE  DESIGN  DOCUMENT  FOR  THE 
GENERIC  DATA  ENTRY  SYSTEM 


1.1  Identification.  This  Data  Base  Design  Document  '")BDD) 
describes  the  detailed  design  of  the  data  base  identified  as  the 
Generic  Data  Base  (GDB)  for  the  Computer  Software  Configuration 
Item  (CSCI)  identified  as  the  Generic  Unit  Entry  System  (GUES)  of 
the  Generic  Data  Entry  System  (GDES) . 


1.2  Purpose.  The  purpose  of  the  GDES  is  to  partially  automate 
the  task  of  the  military  analyst  with  an  integrated  approach  to 
the  preparation  and  management  of  generic  unit  .files  used  in 
creating  a  simulated  tactical  deployment.  The  integrated  data 
base  will  be  compatible  with  the  Communications-Electronics 
Operator  Positioning  System  (CEOPS)  and  will  support  organiza¬ 
tional  tables  of  units,  nets,  operators,  vehicles,  and  equipment 
that  are  deployment-independent. 


1.3  Introduction .  This  DBDD  shall  describe  in  detail  the  GDB 
structure,  description,  interrelationships,  and  design. 


2.1  Government  Documents.  The  following  documents  of  the  exact 
issue  shown  form  a  part  of  this  specification  to  the  extent 
specified  herein.  In  the  event  of  conflict  between  the  documents 
referenced  herein,  and  the  contents  of  this  specification,  the 
contents  of  this  specification  shall  be  considered  a  superseding 
requirement. 


DOD-STD-2 167 


Defense  System  Software  Development,  4  June 
1987 


USAEPG 


Codebook  Methodology  for  Communication 
Electronic  Data  Base,  September  1986 


2 . 2  Non-Government  Documents 


BTO  87-02-010 


Description  of  the  Communications-Electronics 
Operator  Positioning  System  (CEOPS)  Data  Base 
Files,  revised  July  1987 


INGRES  Reference  Manual,  Relational 
Technology,  Inc.,  1983 
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3.1  Data  Base  Management  System  Overview.  INGRES  is  a  rela¬ 
tional  data  base  management  system  developed  by  Relational  Tech¬ 
nology,  Inc,  (RTI) .  QUEL,  the  INGRES  query  language,  which  al¬ 
lows  the  user  to  retrieve,  manage,  and  maintain  data  in  an  exist¬ 
ing  INGRES  data  base.  QUEL  statements  are  either  entered 
directly  through  the  INGRES  terminal  or  embedded  within  programs 
written  in  high-level  languages  via  EQUEL  (Embedded  QUEL) . 

In  INGRES  every  file  uses  exactly  one  record  format.  A  file  is  a 
table  having  rows  and  columns. 


iase  Structure 


3.2.1 


3. 2. 1.1  SRC  Data  Base  Tables.'  Relationships  of  the  key  fields 
in  the  Standards  Requirements  Code  (SRC)  data  base  tables  are 
shown  in  figure  1.  The  SRC  number  field  is  included  as  a  key 
field  in  all  SRC  data  base  tables. 

Information  about  particular  kinds  of  devices,  operating  modes,, 
personnel  functions,  and  security  classifications  independent  of 
SRC  number  is  represented  in  coded  fields  (para  3. 2. 1.3). 

3. 2. 1.2  VTAADS  Data  Base  Tables.  The  GBD  contains  data  ex¬ 
tracted  from  VERTICAL,  the  Army  Authorized  Document  System 
(VTAADS) .  VTAADS  data  base  tables — eq_master,  paragraph,  equip¬ 
ment,  radios,  and  vehicles — contain  information  about  the  quan¬ 
tity  of  equipment  and  personnel  authorized  for  and  issued  to 
generic  military  units.  VTAADS  data  are  less  specific  than 
similar  data  in  SRC  data  base  tables  because  the  particular 
assignments  of  personnel  and  equipment  to  vehicles  is  not  speci¬ 
fied  in  the  VTAADS  data  base  tables.  Also,  the  coded  fields  re¬ 
presenting  types  of  devices  and  personnel  functions  are  not 
present  in  the  VTAADS  data  base  tables  (paras  3. 2. 1.1  and 

3. 2. 1.3).  The  security  classifications  are  coded  differently 
than  in  the  Codebook  and  SRC  data  base  tables. 

The  TOE  number  field  is  included  as  a  key  field  in  all  of  the 
VTAADS  data  base  tables. 

3. 2. 1.3  Codebook  Data  Base  Tables.  Generic  devices,  operating 
modes,  personnel  functions,  and  security  classifications  are 
represented  by  coded  fields  in  the  SRC  and  VTAADS  data  base 
tables.  In  order  to  allow  the  coded  fields  to  be  decoded,  more 
complete  information  about  generic  devices,  operating  modes, 
personnel  functions,  and  security  classifications  is  contained  in 
the  codebook  data  base  tables.  The  codebook  data  base  tables, 
which  include  PTAB,  linenumbs,  nomenclature,  description, 
config_def,  config_ref,  eqp_def,  and  comp_def,  are  keyed 


■.  ...v 


w*?r*;**.«w 


DBDD-C005T0C4D7 


according  to  figure  2,  which  shows  the  relationships  of  the  key 
fields. 

3.2.2  Data  Base  File  Interrelationships 


3. 2. 2.1  SrcHeader  File.  There  ’s  a  record  in  this  file  for  each 
unique  src_number.  Any  other  file  with  an  src_number  field 
defined  can  point  to  that  same  src_number  field  in  this  file  and 
retrieve  the  secur_class,  src_name,  deploy_key,  and  user_id 
fields  from  the  indicated  record. 

3. 2. 2. 2  IntNetHeader  File.  Files  with  have  src_number  and 
net_type  fields  can  point  to  the  these  fields  in  their  file  and 
obtain  the  net_name  and  other  internal  net  information  for  that 
src's  net.  The  src_number  can  be  used  as  a  pointer  into  the 
srcheader  file  to  obtain  the  src  information  for  the  same  record. 

3. 2. 2. 3  ExtNetHeader  File.  The  src_number  and  net_type  fields 
in  this  file  may  be  used  as  pointers  into  the  altnetheader  file 
to  retrieve  the  alternate  net  types  and  src_number  fields.  The 
src_number  or  ext_src_num  can  be  used  as  a  pointer  into  the 
intnetheader  file  to  obtain  the  internal  net  information  for  the 
most  common  net  entered. 

3. 2. 2. 4  AltNetHeader  File.  The  alt_src_num  and  alt_net_type 
fields  may  be  used  as  pointers  into  the  Intnetheader  file's 
src_number  and  net_type  fields  to  obtain  internal  net  header  in¬ 
formation.  The  src_number  and  alt_src_num  fields  must  point  to 
the  src_number  field  in  the  srcheader  file  to  obtain  the  complete 
information  for  that  SRC. 

3. 2. 2. 5  GufQperator  File.  If  the  int_ext_flag  field  contains 
an  "I,"  the  src_number  and  net_type  fields  are  used  as  painters 
into  the  intnetheader  file.  If  the  int_ext_flag  contains  an  "E," 
the  src_number  and  net_type  are  used  as  pointers  into  the 
extnetheader  and  altnetheader  files.  The  src_number, 
operator_id,  and  oper_number  fields  are  used  as  pointers  into  the 
vehicle  file  to  obtain  the  vehicle  information  for  that  operator. 
These  same  fields  may  be  used  as  pointers  in  to  the  mfdcoperator 
file,  if  there  are  deployment  constraints  defined.  See  para¬ 
graphs  3. 2. 2. 7  through  3.2.2.10  for  a  complete  description  of  how 
to  obtain  the  deployment  constraints  for  an  operator. 

3. 2. 2. 6  Vehicle  File.  Within  the  vehicle  file,  the  src_number 
field  is  used  as  a  pointer  into  the  srcheader  file  to  access 
complete  information  for  the  SRC  that  the  operator  is  in.  The 
src_number  field  may  be  used  in  combination  with  the , operator_id 
and  oper_number  fields  to  access  the  gufoperator  file  to  check 
nets  and  equipment  associated  with  that  operator.  The 
src_number,  operator_id,  and  oper_number  fields  are  used  as 
pointers  in  to  the  mfdcoperator  file  to  obtain  the  deployment 
constraints,  if  any.  The  src  number  field  in  this  file  can  be 
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used  as  a  pointer  into  the  srcheader  file  to  obtain  other 
information  on  the  SRC. 


3. 2. 2. 7  MfdcOoerator  File.  The  deploy_key  field  in  the  record 

pointed  to  should  never  be  a  "U" ,  since  this  would  mean  that 
there  is  a  random  uniform  distribution  deployment  in  the  area  and 
there  should  be  no  deployment  constraint  records  required.  The 
src_number,  operator_id,  and  oper_number  fields  may  be  used 
together  as  pointers  into  the  vehicle  file  to  obtain ‘the  vehicle 
information  for  that  operator.  These  same  fields  may  also  be 
used  to  access.,  net  assignments  and  equipment  assigned  to  these 
operators  from  the  guf operator  file.  To  get  complete  deployment 
constraint  information,  the  src_number,  operator_id,  and 
oper_number  fields  are  used  as  pointers  into  the  mfdcmainoper, 
mfdcreloper,  or  specopr  files,  depending  upon  what  is  contained 
in  the  operator_key  field. 


3. 2. 2. 8  MfdcMainOoer  File.  The  src_number,  operator_id,  and 
oper_number  fields  in  this  file  are  used  as  pointers  into  the 
vehicle  file  to  obtain  the  vehicle  information  for  that  operator. 
These  same  fields  may  be  used  to  obtain  net  assignments  and 
equipment  assigned  to  these  operators  from  the  guf operator  file. 


3. 2. 2. 9  MfdcRelOper  File.  The  src_number,  operator_id,  and 
oper_number  fields  in  this  file  are  used  as  pointers  into  the 
vehicle  file  to  obtain  the  vehicle  information  for  that  operator. 
These  fields  may  also  be  used  to  access  net  assignments  and 
equipment  assigned  to  these  operators  from  the  guf operator  file. 
The  src_number, ~rel_oper_id,  and  rel_oper_num  are  used  as  point¬ 
ers  into  the  mfdcmainoper  file  to  obtain  the  deployment  con¬ 
straints  for  that  operator. 


3.2.2.10  SpecOor  File.  SpecOpr  is  an  acronym  used  by  CEOPS  that 
means  special  operator  distribution.  The  src_number,  oper- 
ator_id,  and  oper_number  fields  in  this  file  are  used  as  pointers 
into  the  vehicle  file  to  obtain  the  vehicle  information  for  that 
operator.  These  same  fields  may  be  used  to  obtain  net  assign¬ 
ments  and  equipment  assigned  to  these  operators  from  the  guf- 
operator  file. 


3.2.2.11  CodeGr oup  File.  There  is  a  record  in  this  file  for 
each  unique  code  group  type.  Any  other  file  that  has  a 
code_group  field  can  point  to  the  same  code  group  field  in  this 
file  and  retrieve  the  title,  code_length,  name_length,  and 
class_req  fields  from  the  record  pointed  to. 


3.2.2.12  Nomenclature  File.  The  code_group  field  in  this  file 
may  be  used  as  a  pointer  into  the  codegroup  file  to  obtain 
code_length  of  the  code,  nomen_length  of  the  nomenclature,  the 
title  of  the  code_group,  and  whether  or  not  there  was  a  sec_class 
required  for  this  code_group  type.  The  code_group  and  code  may 
be  used  as  pointers  into  the  description  or  linenumbs  files  to 
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obtain  a  further  description  or  line_id_num  of  the  code,  if  there 
is  any. 

3.2.2.13  Description  File.  The  code_group  field  in  this  file 
may  be  used  as  a  pointer  into  the  codegroup  file  to  obtain  com¬ 
plete  information  for  the  given  code_group  type.  The  code_group 
and  code  fields  may  be  used  as  pointers  into  the  nomenclature 
file  to  obtain  the  nomenclature  and  sec_class  of  the  record. 

3.2.2.14  LineNumbs  File.  The  code_group  field  in  this  file  may 
be  used  as  a  pointer  into  the  codegroup  file  to  obtain  complete 
information  for  the  given  code_group  type.  The  code_group  and 
code  fields  may  be  used  as  pointers  into  the  nomenclature  file  to 
obtain  the  nomenclature  and  sec_class  of  the  record. 

3.2.2.15  Ptab  File.  The  power  and  antenna  table  (PTAB)  file 
yields  a  Boolean  (yes/no,  true/false)  result  when  all  four  fields 
are  specified  in  retrieval.  When  fewer  fields  are  specified,  the 
values  returned  in  the  unspecified  fields  represent  coded 
identifiers.  Complete  information  for  the  meq_code, 
vehicle_code,  and  ant_code  fields  can  be  obtained  by  using  the 
field,  with  a  code-group  as  a  key  into  the  linenumbs, 
description,  and  nomenclature  files.  Complete  information  for 
the  comp_code  field  can  be  obtained  from  the  description  and 
nomenclature  files  in  a  similar  manner.  When  obtaining  complete 
information  in  this  manner,  a  code_group  of  33  is  used  with  the 
meq_code  field,  a  code_group  of  35  for  the  comp_code  field,  a 
code_group  of  40  for  ant_code  field,  and  a  code  group  of  92  for 
the  vehicle_code  field. 

3.2.2.16  Confiq  ref  File.  The  config_ref  file  contains 
configuration  references.  The  config  field  can  be  used  to  look 
up  configuration  definitions  in  the  config_def  file. 

3.2.2.17  Confiq  def  File.  The  config_def  file  contains 
configuration  definitions.  The  ecode  field  can  be  used  to  look 
up  equipment  definitions  in  the  eqp_def  file.  The  n  field  can  be 
used  to  set  a  repetition  count  for  creation  of  GUF-operator 
records . 

3.2.2.18  Ectp  def  File.  The  eqp_def  file  contains  equipment 
definitions  for  radio  equipment  items.  The  ccode  field  ma;.  be 
used  to  determine  the  value  for  the  comp_code  field  when  creating 
guf_operator  records,  and  to  look  up  component  information  in  the 
comp_def  file.  The  n  field  may  be  used  to  determine  the  number 
of  records  when  creating  guf_operator  records. 

3.2.2.19  Comp  def  File.  The  comp_def  file  contains  component 
definitions.  The  emit_code  field  may  be  used  to  determine  the 
emitter_code  field  when  GUf-operator  records  are  being  created. 
The  nomen  and  sec_class  fields  may  be  used  similarly  to  the 
corresponding  fields  in  the  nomenclature  table. 
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3.2.2.20  Ea  Master  File.  The  eq_master  field  contains  the  TOE 
header  record  information  from  VTAADS  (fig  3) . 

3.2.2.21  Paragraph  File.  The  paragraph  file  contains  the 
paragraph  header  records  from  VTAADS.  The  toe_number  and 
para_num  fields  may  be  used  to  look  up  information  in  the  radios 
and  vehicle  files. 

3.2.2.22  Personnel  File.  The  personnel  file  contains  infor¬ 
mation  from  the  personnel  records  of  VTAADS. 

3.2.2.23  Equipment  File.  The  equipment  file  contains 
information  from  the  equipment  records  of  VTAADS.  The 
line_id_num  field  may  be  used  to  look  up  information  in  the 
linenumbs  file. 

3.2.2.24  Radios  File.  The  radios  file  is  a  join  of  the 
equipment  file  with  the  linenumbs  file,  where  code_group  =  33. 

3.2.2.25  Vehicles  File.  The  vehicles  file  is  a  joint  of  the 
equipment  file  with  the  linenumbs  file  where  code_group  =  92. 

3 . 3  Data  Base  File  Design 

3.3.1  SrcHeader  File.  The  srcheader  file  contains  one  unique 
record  for  each  SRC  in  the  data  base.  The  src_number  field 
within  this  file  is  the  key  field  that  links  all  other  records  in 
the  other  files  to  a  specific  SRC  (unit) .  This  file  currently 
contains  897  records  stored  in  a  binary  tree  (BTREE)  structure. 

3. 3. 1.1  SrcHeader  Record.  The  srcheader  record  is  76  bytes  long 
and  contains  five  fields  that  are  uniquely  keyed  on  the  src_ 
number  field. 
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3. 3. 1.1.1  Secur  Class  Field.  The  secur_class  field  is  a  one 
alphanumeric  ASCII  character  field.  It  designates  the  level  of 
security  applicable  to  the  data  associated  with  the  SRC  in  this 
file.  The  valid  entries  are  listed  in  the  table  1. 

TABLE  1.  Security  Classification  Code 
Code  Classification 

0  UNCLASSIFIED 

1  CONFIDENTIAL 

2  SECRET 

3  TOP  SECRET 

4  FOR  OFFICIAL  USE  ONLY 

5  CONFIDENTIAL  NOFORN 

6  SECRET  NOFORN 

7  TOP  SECRET  NOFORN 

8  NATO  CONFIDENTIAL 

9  NATO  SECRET 

A  PROPRIETARY  INFORMATION 

B  CONFIDENTIAL  US/UK  EYES  ONLY 

C  SECRET  US/UK  EYES  ONLY 

3. 3. 1.1. 2  SRC  Number  Field.  The  src_number  field  consists  of  13 
ASCII  alphanumeric  characters.  The  SRC  number  is  based  on  Table 
of  Organization  and  Equipment  (TOE)  numbers.  The  13  characters 
are  subdivided  into  the  following  seven  items. 

a.  Characters  1-2  are  alphabetic  and  represent  the  country 
of  origin.  (i.e.,  US  =  United  States,  GE  =  West  Germany). 

b.  Characters  3-4  are  numeric  and  represent  the  SRC  base 
number.  The  base  number  indicates  the  branch  or  major 
subdivision  of  a  TOE.  (i.e.,  11  =  Signal,  17  =  Armor). 

c.  Characters  5-7  are  numeric  and  represent  the  SRC 
subnumber.  The  last  digit  of  the  subnumber  describes  the 
organizational  level  of  the  unit.  (i.e.,  5  =  Battalion,  4  = 
Division) . 

d.  The  eighth  character  is  alphabetic  and  represents  the 
SRC  suffix.  It  indicates  the  revision  series. 

e.  The  ninth  character  is  numeric  and  represents  the  year 
of  publication.  It  is  derived  from  the  last  digit  of  the  year 
the  TOE  was  published. 

f.  Characters  10-11  are  alphanumeric  and  represent  the  SRC 
variation  code.  It  indicates  the  variations  that  apply  to  the 
organizational  elements  of  the  TOE. 


g.  Characters  12-13  are  numeric  and  represent  the  SRC 
change  number.  This  number  is  assigned  by  the  TOE  proponent  and 
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denotes  the  applicable  change  that  a  TOE  contains.  Change  number 
99  denotes  changes  not  yet  published. 

3. 3. 1.1. 3  SRC  Name  Field.  The  src_name  field  is  a  48  alpha¬ 
numeric  ASCII  character  field.  This  field  contains  the  format 
name  of  the  TOE  unit  associated  with  the  SRC. 

3. 3. 1.1. 4  Deploy  Kev  Field.  The  deploy_key  (deployment  key 
code)  field  is  a  one  alphabetic  ASCII  character  field.  This 
field  establishes*  whether  the  operators  are  to  be  placed  randomly 
within  the  unit  area,  or  placed  individually  according  to  the 
data  in  the  MFDC.  The  valid  entries  are:  U  *  to  be  placed  ran¬ 
domly,  or  N  =  to  be  placed  in  accordance  with  the  MFDC,  however 
if  not  found,  it  will  default  to  random  deployment;  S  *  placed  in 
accordance  with  the  MFDC  and  if  not  found  output  will  terminate. 

3. 3. 1.1. 5  User  ID  Field.  The  user_id  (user  identification) 
field  is  a  nine  alphanumeric  ASCII  character  field.  It  iden¬ 
tifies  the  user  currently  working  or  the  user  who  last  worked  the 
SRC  represented  by  this  record.  This  information  is  used  to 
restrict  other  users  from  modifying  any  records  associated  with 
this  SRC  currently  being  worked  on,  and/or  to  identify  the 
individual  who  created  or  last  modified  the  SRC. 

3.3,2  IntNetHeader  File.  The  intnetheader  file  identifies  the 
internal  nets  unique  to  a  specific  SRC.  A  net  is  considered 
internal  to  an  SRC  when  the  net  control  station  (NCS)  is. provided 
by  that  SRC.  This  field  currently  contains  327  records  stored  in 
a  BTREE  structure. 

3. 3. 2.1  IntNetHeader  Record.  The  intnetheader  record  is  66 
bytes  long  and  contains  nine  fields  that  are  uniquely  keyed  on 
the  src_number  and  net_type  fields. 

3. 3. 2. 1.1  SRC  Number  Field.  For  a  description  of  the  src_number 
field,  see  paragraph  3. 3. 1.1. 2. 

3. 3. 2. 1.2  Net  Type  Field.  The  net_type  field,  composed  of  six 
alpha-numeric  ASCII  characters,  identifies  the  type  of  net  into 
which  a  particular  communications  equipment  and  operator  will 
enter.  An  asterisk  wildcard  character  may  be  used  in  the  first, 
second,  third,  or  sixth  positions  of  this  field.  The  net  type 
number  is  subdivided  into  the  following  five  subfields: 

a.  Subfield  1  is  a  one-character  numeric  field  identifying 
the  category  of  users  establishing  the  net.  Table  2  lists  the 
valid  net  category  numbers  with  the  definitions. 
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TABLE  2.  Category  of  Force  Element  Establishing  the  Net 


Numb e 3 


Def initioi 


0 

1 

2 

3 

4 

5 

6 

7 

8 
9 


Reserved  for  future  expansion 

US  ground  forces 

US  air  forces 

NATO  ground  forces 

NATO  air  forces 

Reserved  for  future  expansion 

Enemy  ground  forces 

Enemy  air  forces 

Reserved  for  future  expansion 

Reserved  for  future  expansion 


b.  Subfield  2  is  a  one-character  alphanumeric  field 
identifying  the  branch  of  an  organization  or  a  category  of  net. 
Table  3  lists  the  valid  entries  and  their  definitions. 


TABLE  3 .  Branch  or  Category  of  Net 


Code 


A  Armor 

B  Air  defense  artillery 

C  Chemical 

D  Medical 

E  Engineer 

F  Field  artillery 

G  Military  police 

H  Composite 

I  Infantry/rangers/light  infantry 

J  Military  intelligence/communications 

electronics  warfare  and  intelligence 
( CEWI ) 

K  Other 

L  Airborne 

M  Mechanized/motorized 

N  Special  forces 

0  Ordnance 

P  Psychological  operations 

Q  Quartermaster 

R  Airmobile/air  assault 

S  Signal 

T  Transportation 

U  Aviation 

V  Air  Force 

W  Marine 

X  Navy 

Y  Reserved  for  future  expansion 

Z  Reserved  for  future  expansion 

0  Reserved  for  future  expansion 
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TABLE  3. 


1  Reserved  for  future  expansion 

Branch  or  Category  of  Net  (continued) 

Code  Branch  or  Category 


Code  Branch  or  Category 

2  Reserved  for  future  expansion 

3  Reserved  for  future  expansion 

4  Navigational  aids 

5  Non-RF 

6  Radar 

7  Satellites 

8  Holding  nets  electronic  warfare 
(reserved) 

9  Multichannel 

c.  Subfield  3  is  a  one-character  numeric  field  identifying 
the  echelon  of  the  organization  establishing  the  net.  Table  4 
lists  the  valid  entries  for  this  subfield  and  their  definition. 

TABLE  4.  Echelon  Establishing  the  Net  Type 


A  Corps  area  multichannel 

0  Platoon,  section,  squad,  team,  detachment,  flight 

1  Company,  troop,  battery,  air  force  squadron 

2  Battalion,  cavalry  squadron 

3  Regiment,  group,  wing 

4  Brigade,  support  command 

5  Division,  or  Div  Multichannel/MSE  or  air  division 

6  Corps  or  Corps  MSE,  or  tactical  air  force 

7  Army 

8  Theater  Army 

9  Unified/Special  Command,  Department  of  Defense 

N  MSE  node 

M  MSRT-to-RAU 

d.  Subfield  4  is  a  one-character  numeric  field  identifying 
the  frequency  range  within  which  the  net  operates.  When  equip¬ 
ment  has  a  tuning  range  that  allows  operation  in  more  than  one 
band,  that  band  most  coincident  with  the  tunable  range  of  the 
equipment  should  be  used. 

Table  5  lists  valid  codes  for  this  subfield.  The  code  number  is 
even  or  odd,  depending  upon  net  type  and  purpose  indicated  in 
table  6. 
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TABLE  5.  Frequency  Range  Bands  for  Net 


Code  Band 


Frequency 


Frequency  Description 


0 

or 

1 

I 

3  kHz-1.99  MHz 

2 

or 

3 

II 

2  MHz-19.99  MHz 

4 

or 

5 

III 

20  MHZ-244.99  MHz 

6 

or 

7 

IV 

225  MHZ-2.99  GHz 

8 

or 

9 

V 

3  GHz -3 00  GHz 

Very  Low  Frequency  (VLF) ,  Low 
Frequency  (LF) ,  Medium 
Frequency  (MF) 

High  frequency  (HF) 

Very  high  frequency  (VHF) 
Ultrahigh  frequency  (UHF) , 
Super  high  frequency  (SHF) , 
Extremely  high  frequency  (EHF) 


e.  Subfield  5  is  a  two-character  alphanumeric  field 
identifying  the  function  of  the  net.  Table  6  lists  the  valid 
codes  and  the  associated  function.  If  subfield  4  is  odd,  the 
function  under  the  odd  number  column  is  appropriate;  and  if  it  is 
even,  the  even  number  column  is  appropriate. 


Code 


TABLE  6.  Primary  Purpose  of  the  Net 


Even  number 


Odd  number 


00 

- 

10 

11 

- 

20 

21 

- 

30 

31 

- 

35 

36 

- 

39 

40 

* 

49 

50 

99 

Command/ operations 
Operations/ intelligence 
Administration/logistics 
Fire  direction 
reserved 

Direction  finding/ 


Hold  Nets 


Operations 
Intelligence 
Reserved  for  expansion 
Radio  wire  integration 
Reserved 

Area  communications 
j  amming/ intercept/ 
other  EW 

Air  traffic  control 


3. 3. 2. 1.3  Net  Name  Field.  The  net_name  field  is  a  28  alpha¬ 
numeric  ASCII  character  field.  It  may  be  any  valid  character 
string  and  must  be  left-justif ied.  This  field  is  the  name  of  the 
net  plus  an  indication  of  its  function  and  echelon. 


3. 3. 2. 1.4  Mod  Code  Field.  The  mod_code  (modulation  code)  field 
is  a  five  numeric  ASCII  character  field.  It  designates  the  RF 
modulation  type  which  the  net  type  most  habitually  operates.  The 
valid  codes  and  their  meanings  are  contained  in  the  nomencla¬ 
ture  file. 


3. 3. 2. 1.5  Num  Channels  Field.  The  num_cl.annels  (number  of  chan¬ 
nels)  field  is  a  three  numeric  ASCII  character  field.  It  des¬ 
ignates  the  number  of  channels  for  a  multichannel  net.  It  is 
blank  for  single-channel  nets. 

3. 3. 2. 1.6  Pulse  Reo  Rt  Field.  The  pulse_rep_rt  (pulse  repeti¬ 
tion  rate)  field  is  a  four-byte  floating  point  field  and  rep¬ 
resents  the  pulse  rate  of  the  equipment  in  pulses  per  second 
(P/s)  . 
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3. 3. 2. 1.7  Pulse  Width  Field.  The  pulse_width  field  is  a  four- 
byte  floating  point  field  that  indicates  the  pulse  in  tenths  of 
microseconds . 

3. 3. 2. 1.8  Protect  Freo  Field.  The  protect_freq  (protected 
frequency)  field  iu  a  one  alphabetic  ASCII  character  field.  The 
only  valid  entries  are  P  for  protected  frequencies  and  blank  for 
non-protected  frequencies. 

3. 3. 2. 1.9  Net  Function  Field.  The  net_f unction  field  is  a  one 
alphabetic  ASCII  character  field  designating  the  primary  function 
for  which  the  net  is  used.  The  valid  entries  and  their  meanings 
are  listed  in  the  table  7. 

TABLE  7.  Functional  Coding  for  Nets 

Code  Function 

R  Command/Operations 

2  Operations 

F  Intelligence 

U  Operations/Intelligence 

K  Administration/Logistics 

0  Fire  Direction 

7  Air  Traffic  Control 

D  EW  Direction  Finding/ Jamming/ 

Intercept/Other  EW 
N  Radio  Wire  Integration 

P  Area  Communication 

H  Spare/Hold  Net 

3.3.3  ExtNetHeader  File.  The  extnetheader  file  identifies 
external  nets  unique  to  a  specific  SRC.  A  net  is  considered 
external  when  the  NCS  for  the  net  is  provided  by  a  different  SRC. 
This  file  currently  contains  4629  records  stored  in  an  BTREE 
structure . 

3. 3. 3.1  ExtNetHeader  Record.  The  3 4 -byte  extnetheader  record 
contains  four  fields  that  are  uniquely  keyed  on  the  src_number 
and  net_type  fields. 

3. 3. 3. 1.1  SRC  Number  Field.  For  a  description  of  the 
src_number  field,  see  paragraph  3. 3. 1.1. 2. 

3. 3. 3. 1.2  Net  Type  Field.  For  a  description  of  the  net_type 
field,  see  paragraph  3. 3. 2. 1.2. 

3. 3. 3. 1.3  NIC  Code  Field.  The  nic_code  (net  information  code) 
field  is  a  two  alphanumeric  ASCII  character  field.  This  field 
indicates  the  relationship  between  the  unit  to  which  the  operator 
belongs  and  the  unit  providing  the  net  control  station  (NCS)  for 
the  external  net  that  the  operator  will  join.  The  valid  entries 
and  their  meaning  are  listed  in  table  2-13,  Unit  Subordination 
Codes,  in  Description  of  the  CEOPS  Data  Base  Files. 
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3. 3. 3. 1.4  Ext  SRC  Num  Field.  The  ext_src_num  field  designates 
the  SRC  that  serves  as  the  NCS  for  the  external  net  listed.  For 
a  description  of  the  SRC  field  see  paragraph  3. 3. 1.1. 2. 

3.3.4  AltNetHeader  File.  The  altnetheader  file  contains  alter¬ 
nate  nets  that  are  associated  with  a  specific  external  net  in  the 
extnetheader  file.  There  may  be  up  to  eight  alternate  nets  for 
each  primary  external.  The  key  fields  that  link  the  two  files 
are  the  src_number  and  net_type.  This  file  currently  contains 
5424  records  stored  in  a  BTREE  structure. 

3. 3. 4.1  AltNetHeader  Record.  The  altnetheader  record  is  39 
bytes  long  and  contains  five  fields  that  are  uniquely  keyed  on 
the  src_number,  net_type,  and  alt_order  fields. 

3. 3. 4.1.1  SRC  Number  Field.  For  a  description  of  the  src_number 
field,  see  paragraph  3. 3. 1.1. 2. 

3. 3. 4. 1.2  Net  Type  Field.  For  a  description  of  the  net_type 
field,  see  paragraph  3. 3. 2. 1.2. 

3. 3. 4. 1.3  Alt  Order  Field.  The  alt_order  field  is  a  one  numeric 
ASCII  character  field  which  designates  the  order  of  priority  of 
alternate  external  nets.  There  is  a  limit  of  eight  alternates 
per  primary  net,  therefore,  the  valid  entries  are  1-8. 

3. 3. 4. 1.4  Alt  Net  Type  Field.  For  a  description  of  the 
alt_net_type  field,  see  paragraph  3. 3. 2. 1.2. 

3. 3. 4. 1.5  Alt  SRC  Num  Field.  For  a  description  of  the 
alt_src_num  field,  see  paragraph  3. 3. 1.1. 2. 

3.3.5  Guf Operator  File.  The  gufoperator  file  identifies  each 
unique  operator  within  a  specific  external  or  internal  net, 
within  a  specific  SRC.  It  also  defines  the  radio  frequency  (RF) 
emitters  and  receivers  used  by  the  operator.  This  file  currently 
contains  22653  records  stored  in  a  BTREE  format. 

3. 3. 5.1  Guf Operator  Record.  The  gufoperator  record  is  52  bytes 
long  and  contains  17  fields  that  are  uniquely  keyed  on  the 
src_number,  net_type,  int_ext_f lag,  operator_id,  oper_number,  and 
emitter_code  fields. 

3. 3. 5. 1.1  3RC_Number  Field.  For  a  description  of  the  src_number 
field,  see  paragraph  3. 3. 1.1. 2. 

3. 3. 5. 1.2  Net  Type  Field.  For  a  description  of  the  net_type 
field,  see  paragraph  3. 3. 2. 1.2. 
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.3. 3. 5. 1.3  Int  Ext  Flag  Field.  The  int_ext_flag  field  is  a  one 
numeric  ASCII  character  field  which  identifies  the  associated  net 
as  either  internal  or  external.  Valid  entries  are  "I”  for  in¬ 
ternal,  or  "E"  for  external. 

3. 3. 5. 1.4  NCS  Code  Field.  The  ncs_code  (net  contrc1  station) 
field  is  a  one  numeric  ASCII  character  field  which  designates  the 
operator  and  his  equipment  as  either  the  NCS  or  an  operator  in 
the  net.  The  valid  entries  are;  0  for  NCS,  1  for  an  operator 
whose  NCS  is  an  external  operator,  2  for  the  external  operator 
who  serves  as  the  NCS,  and  3  for  a  normal  operator  in  the  net. 

3. 3. 5. 1.5  Line  Number  Field.  The  line_number  field  is  a  six 
alphanumeric  ASCII  character  field.  The  number  is  obtained  from 
the  TOE  or  a  supply  document,  and  is  used  within  the  military  as 
an  equipment  identifier. 

3. 3. 5. 1.6  Para  Number  Field.  The  para_number  field  is  a  two 
alphanumeric  ASCII  character  field.  The  field  indicates  the 
paragraph  number  within  the  TOE  for  the  operator  and  equipment. 

3. 3. 5. 1.7  Mult  Net  Ent  Field.  The  mult_net_ent  (multiple  net 
entry)  field  is -a  one  numeric  ASCII  character  field.  This  field 
identifies  the  number  of  nets  an  operator  and  specific  piece  of 
equipment  will  enter.  This  field  is  normally  left  blank,  which 
indicates  it  will  operate  in  only  one  net. 

3. 3. 5. 1.8  Alloc  Code  Field*  The  alloc_code  (allocation)  field 
is  a  one  numeric  ASCII  character  field.  This  field  indicates 
what  processing  will  be  done  for  an  operator  who  cannot  be 
assigned  to  an  external  net  through  information  contained  in  the 
NIC  field.  Valid  entries  are:  0  =  the  operator  must  be  assigned 
manually  if-  automatic  assignment  fails,  1  =  the  operator  must  be 
assigned  if  the  NIC  relationship  exists,  and  2  *  the  operator 
need  not  be  assigned  if  automatic  assignment  fails. 

3. 3. 5. 1.9  Operator  ID  Field.  The  operator_id  field  is  a  four- 
numeric  coded  ASCII  character  field  identifying  the  operator  of  a 
piece  of  RF  equipment.  The  meaning  of  the  codes  are  contained  in 
the  nomenclature  file  and  only  codes  contained  in  that  file  are 
valid  entries. 

3.3.5.1.10  Oper  Number  Field.  The  oper_number  field  is  a  two 
alphanumeric  ASCII  character  field  used  to  further  identify  like 
operators  within  the  same  SRC.  As  an  example:  three  platoon 
leaders  in  the  same  unit  would  be  01,  02,  and  03.  Valid  entries 
are  00-99,  and  A0-Z9. 

3.3.5.1.11  Meg  Code  Field.  The  meq_code  (major  equipment)  field 
is  a  three  alphanumeric  ASCII  character  field.  It  is  a  coded 
field  that  identifies  the  majpr  pieces  of  equipment.  The  meaning 
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of  the  codes  are  contained  in  the  nomenclature  file,  and  only  the 
codes  in  this  file  are  valid  entries. 

3.3.5.1.12  Como  Code  Field.  The  comp_code  (component)  field  is 
a  three  alphanumeric  ASCII  character  field.  It  is  a  coded  field 
that  identifies  a  component  of  a  major  piece  of  equipment.  The 
meaning  of  the  codes  are  contained  in  the  nomenclature  file,  and 
only  the  entries  in  this  file  are  considered  valid  entries. 

3.3.5.1.13  Emitter  Code  Field.  The  emitter_code  field  is  a  one 
alphabetic  ASCII  character  field  which  describes  the  functioning 
of  a  piece  of  RF  equipment.  The  following  table  lists  the  valid 
entries  and  their  meaning. 

TABLE  8.  Emitter/Receptor/Target/Sensor  Code 

CLOds  Equipment 

X  RF  communication  transmitter 

R  RF  communications  receiver 

T  RF  communication  transceiver 

J  RF  j  ammer 

I  RF  intercept  receiver 

D  RF  direction  finding  (DF)  receive*: 

K  Rf  receiver  component  of  a  jammer 

equipment 

F  RF  intercept  and  DF  receiver 

G  RF  jammer  transceiver 

w  RF  warning  receiver 

Z  RF  self-defense  jammer 

C  Radar 

M  Radar  image  target 

H  IR  target  (heat  emitter) 

Q  IR  sensor  or  DF 

V  Visual  target 

P  Photographic  sensor 

L  Low  light  level  sensor  or  DF 

B  Visual  sensor  (glasses) 

S  Visual  sensor  (unaided  vision) 

A  Audio 

E  Unaided  audio  sensor  or  DF 

N  Audio  sensor  or  DF  aided  by 

amplification 

3.3.5.1.14  Svs  ID  Code  Field.  The  sys_id_code  (system 
identification)  field  is  a  two  alphanumeric  ASCII  field.  This 
field  farther  identifies  major  equipment  as  part  of  a  system, 
such  as  TACFIRE.  The  codes  and  their  meanings  for  this  field  can 
be  found  in  the  nomenclature  file;  these  are  the  only  valid 
codes . 
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3.3.5.1.15  Comsec  Code  Field.  The  comsec_code  (communication 
security)  field  is  a  two  alphanumeric  ASCII  character  field  that 
identifies  Comsec  equipment.  The  valid  codes  and  their  meanings 
can  be  found  in  the  nomenclature  file. 

3.3.5.1.16  Ant  Code  Field.  The  ant_code  (antenn$0  field  is  a 
three  alphanumeric  ASCII  character  field  that  identifies  an 
antenna.  The  valid  codes  and  their  meanings  can  be  found  in  the 
nomenclature  file. 

3.3.5.1.17  Eouip_Sea  Field.  The  equip_seq  field  is  a  one-byte 
integer  field  containing  the  equipment  sequence  number.  This 
field  may  be  used  with  the  meq__code  field  to  uniquely  identify  a 
major  equipment  item  used  by  a  specific  operator.  Equipment  is 
sequenced  in  numerical  order. 

3.3.6  Vehicle  File.  The  vehicle  file  identifies  each  unique 
operator  within  an  SRC  and  the  vehicle  he  is  associated  with. 

This  field  currently  contains  22780  records  stored  in  an  BTREE 
structure . 

3. 3. 6.1  Vehicle  Record.  The  vehicle  record  is  27  bytes  long  and 
contains  six  fields  that  are  uniquely  keyed  on  the  src_number, 
operator_id,  and  oper_number  fields. 

3. 3. 6. 1.1  SRC_Number  Field.  For  a  description  of  the  src  number 


3. 3. 6. 1.1  SRC_Number  Field.  For  a  description  of  the  src_number 
field,  see  paragraph  3. 3. 1.1. 2. 

3. 3. 6. 1.2  Operator  ID  Field.  For  a  description  of  the  oper- 
ator_id  field,  see  paragraph  3. 3. 5. 1.9. 

3. 3. 6. 1.3  Oper  Number  Field.  For  a  description  of  the 
oper_number  field,  see  paragraph  3.3.5.1.10. 

3. 3. 6. 1.4  Vehicle  Code  Field.  The  vehicle_code  field  is  a  three 
alphanumeric  ASCII  field  that  identifies  a  vehicle.  The  valid 
codes  and  their  meanings  can  be  found  in  the  nomenclature  file. 

3. 3. 6. 1.5  Veh  Confjq  Field.  The  veh_config  (vehicle  configur¬ 
ation  field  is  a  three  alphanumeric  ASCII  field  that  identifies 
specific  radio  configurations  for  certain  vehicles.  The  valid 
codes  and  their  meanings  can  be  found  in  the  nomenclature  file. 

3. 3. 6. 1.6  Vehicle  Sec  Field.  The  vehicle_seq  field  is  a  three 
numeric  ASCII  character  field.  All  vehicles  within  an  SRC  are 
sequentially  numbered  utilizing  this  field.  Valid  entries  are 
001-999. 

3.3.7  MfdcQperator  File.  The  mfdcoperator  file  identifies  each 
unique  operator  within  a  specific  SRC  and  assigns  an  operator  key 
code  to  each  operator.  Based  on  the  operator  key  code,  the  oper¬ 
ator  deployment  constraints  will  be  obtained  from  one  of  the  fol- 
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lowing  three  files;  mfdcmainoper,  mfdcreloper,  or  specopr.  This  ^ 
file  currently  contains  no  records  stored  in  a  BTREE  structure. 

3. 3. 7.1  MfdcOoerator  Record.  The  mfdcoperator  record  is  22 
bytes  long  and  contains  five  fields  that  are  uniquely  keyed  on 

the  src_number,  operator_id,  and  oper_number  fields.  £ 

3. 3. 7. 1.1  SRC_Number  Field.  For  a  description  of  the  src_number  -r 

field,  see  paragraph  3. 3. 1.1. 2.  /J 


3. 3. 7. 1.2  Operator  Kev  Field.  The  operator_key  field  is  a  one  v 

alphabetic  ASCII  character  field  which  defines  the  way  the  oper-  ^ 

ator  is  deployed.  The  valid  entries  and  their  meanings  are 

listed  in  table  2-14,  Operator  Key  Codes,  in  Description  of  the 
CEOPS  Data  Base  Files.  v| 

y. 

3. 3. 7. 1.3  Operator  ID  Field.  For  a  description  of  the  oper- 

ator_id  field,  see  paragraph  3. 3. 5. 1.9.  v; 

*  a 

3. 3. 7. 1.4  Oper  Number  Field.  For  a  description  of  the 
oper_number  field,  see  paragraph  3.3.5.1.10. 

3. 3. 7. 1.5  Subtroop  Num  Field.  The  subtroop_num  field  is  a  one 
numeric  ASCII  field.  The  field  is  used  to  further  define  subor¬ 
dinate  elements  of  an  existing  SRC  for  deployment  purposes.  Valid 
entries  are  1-9. 

3.3.8  MfdcMainOper  File.  The  mfdcmainoper  file  has  a  record  for  £• 
each  operator  within  an  SRC  that  has  his  own  set  of  deployment 
constraints.  These  operators  are  referred  to  as  main  operators. 

This  file  currently  contains  one  record  stored  in  a  BTREE  struc¬ 
ture  . 


3. 3. 8.1  MfdcMainOper  Record.  The  mfdcmainoper  record  is  39  o 
bytes  long  and  contains  11  fields  that  are  uniquely  keyed  on  the 
src_number,  operator_id,  oper_number,  and  posture_code  fields. 

3. 3. 8. 1.1  SRC_Number  Field.  For  a  description  of  the  src_number  o', 
field,  see  paragraph  3. 3. 1.1. 2. 

3. 3. 8. 1.2  Operator  ID  Field.  For  a  description  of  the  oper-  v 

ator_id  field,  see  paragraph  3. 3. 5. 1.9.  V 

3. 3. 8. 1.3  Oper  Number  Field.  For  a  description  of  the 
operator_num  field,  see  paragraph  3.3.5.1.10. 

3. 3. 8. 1.4  Posture  Code  Field.  The  posture_code  field  is  a  one 
alphabetic  ASCII  character  field  which  defines  the  activity  level 
of  the  unit  to  which  the  operator  belongs.  Table  9  lists  the 
valid  entries  and  their  meanings. 
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TABLE  9 .  Unit  Posture  Codes 


Code  Posture 


R 

C 

L 

S 

M 

H 

P 

W 

D 


Reserve 
No  contact 
Light  combat 
Second  echelon 
Moderate  combat 
Heavy  combat 
Priority  combat 
Nuclear  warning 
Nuclear  delivery 
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3. 3. 8. 1.5  Activ  Code  Field.  The  activ_code  (activity)  field 
consists  of  one  alphanumeric  ASCII  character.  This  field  defines 
the  type  of  activity  or  operation  in  which  a  unit  is  engaged. 

This  field  is  intended  to  function  as  a  modifier  of  the  unit 
posture_code  whenever  the  posture_code  factor  appears  inadequate 
to  reflect  the  traffic  loading  expected  in  some  special  or 
unusual  type  of  scenario-oriented  situation.  Table  10  lists  the 
valid  entries  with  the  associated  meaning. 


TABLE  10.  Unit  Activity  Codes 


Code 


0  Activity  not  applicable;  i.e.,  needline  not 

qualified  by  an  activity  indicator 
A  Attacking,  counter-attacking,  or 

reconnoitering  in  force 
B  Conducting  exploitation  or  pursuit 

C  Defending,  delaying,  or  screening 

D  Conducting  passage  of  lines  (moving  unit)  or 

relief  in  place  (relieved  unit) 

E  Conducting  passage  of  lines  (stationary  unit) 

or  relief  in  place  (relieved  unit) 

F  Marching  (road  or  cross-country  march) 

G  Moving  to  contact 

H  Part  of  covering  force 

J  Clearing  minefield  or  obstacle 

K  Crossing  minefield 

L  Crossing  river 

M-Z  Reserved  for  future  use 

3. 3. 8. 1.6  Width  Dist  Field.  The  width_dist  (width  distribution) 
field  is  a  one  alphabetic  ASCII  character  field.  This  field 
describes  the  type  of  distribution  used  to  position  the  oper¬ 
ators.  For  valid  entries  and  their  meanings,  see  table  2-14, 
Distribution  Codes  and  Parameters,  in  Description  of  the  CEOPS 
Data  Base  Files. 

3. 3. 8. 1.7  Width  Paraml  Field.  The  width_paraml  (first  width 
parameter)  field  is  a  six  numeric  ASCII  character  field.  The 
entries  for  this  field  are  dependent  on  the  Width  Distribution 
Code,  and  are  described  in  table  2-14  in  Description  of  the  CEOPS 
Data  Base  Files. 

3.3.8. 1.8  Width  Param2  Field.  For  a  description  of  the 
width_param2  (second  width  parameter)  field,  refer  to  paragraph 
3. 3. 8. 1.7. 

3. 3. 8. 1.9  Depth  Dist  Field.  For  a  description  of  the  depth_dist 
(depth  distribution)  field  refer  to  paragraph  3. 3. 8. 1.6. 
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3.3.8.1.10  Depth  Paraml  Field.  For  a  description  of  the 
depth_paraml  (first  depth  parameter)  field,  refer  to  paragraph 
3. 3. 8. 1.7. 

3.3.8.1.11  Depth  Param2  Field.  For  a  description  of  the 
depth_param2  (second  depth  parameter)  field  refer  to  paragraph 
3. 3. 8. 1.7. 

3.3.9  MfdcRelQper  File.  The  mfdcreloper  file  contains  a  record 
for  each  operator  within  an  SRC* who  is  deployed  in  accordance 
with  the  constraints  given  to  a  main  operator.  These  operators 
are  referred  to  as  related  operators  and  are  linked  to  a  main 
operator  in  the  mfdcmainoper  file  by  the  srcjnumber,  rel_oper_id, 
and  rel_oper_num  fields.  This  field  currently  contains  no 
records  stored  in  a  BTREE  structure. 

3. 3. 9.1  MfdcRelQper  Record.  The  mfdcreloper  record  is  25  bytes 
long  and  contains  five  fields  that  are  uniquely  keyed  on  the 
src_number,  operator_id,  and  oper_number  fields. 

3. 3. 9. 1.1  SRCNumber  Field.  For  a  description  of  the  src_number 
field,  see  paragraph  3. 3. 1.1. 2. 

3. 3. 9. 1.2  Operator  ID  Field.  For  a  description  of  the 
operator_id  field,  see  paragraph  3. 3. 5. 1.9. 

3. 3. 9. 1.3  Qper  Number  Field.  For  a  description  of  the 
oper_number  field,  see  paragraph  3.3.5.1.10. 

3. 3. 9. ,1.4  Rel  Qper  ID  Field.  For  a  description  of  the 
rel_oper_id  (related  operator  ID)  field,  see  paragraph  3. 3. 5. 1.9. 

3. 3. 9. 1.5  Rel  Qper  Num  Field.  For  a  description  of  the 
rel_oper_num  (related  operator  number)  field,  see  paragraph 
3.3.5.1.10. 

3.3.10  SpecQpr  File.  The  specopr  file  identifies  operators 
within  an  SRC  that  are  to  be  deployed  with  another  SRC  (unit) . 
This  operator  is  also  considered  a  main  operator  and  is  listed  in 
the  mfdcmainoper  file  with  his  deployment  constraints.  This  file 
(specopr)  contains  the  primary  and  up  to  five  alternate  SRC's 
that  the  operator  could  be  deployed  with.  This  file  currently 
contains  no  records  stored  in  a  BTREE  structure. 

3.3.10.1  SpecQpr  Record.  The  specopr  record  is  37  bytes  long 
and  contains  seven  fields  that  are  uniquely  keyed  on  the 
src_number,  operator_id,  oper_number,  and  mu_order  fields. 

3.3.10.1.1  SRC_Number  Field.  For  a  description  of  the 
src_number  field,  see  paragraph  3. 3. 1.1. 2. 
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3.3.10.1.2  Operator  ID  Field.  For  a  description  of  the 
operator_id  field,  see  paragraph  3. 3. 5. 1.9. 

3.3.10.1.3  Qper  Number  Field.  For  a  description  of  the 
oper_number  field,  see  paragraph  3.3.5.1.10. 

3.3.10.1.4  URC  Code  Field.  For  the  description  of  the  urc_code 
(unit  relationship  code)  field,  see  paragraph  3. 3. 3. 1.3.  The 
urc_code  field  and  the  nic_code  field  are  identical. 

3.3.10.1.5  OAC  Code  Field.  The  oac_code  (operator  assignment 
code)  field  is  a  two  alphanumeric  ASCII  character  field.  This 
field  establishes  the  rules  for  assigning  operators  to  units  that 
match  both  the  URC  and  SRC  given  in  the  previous  fields.  The 
field  is  divided  into  two  subelements  as  follows. 

3.3.10.1.5.1  The  first  subelement  can  be  one  of  the  following: 

S  Assigns  the  operators  sequentially  to  the  valid  move 

troops.  If  there  are  more  operators  than  move  troops, 
the  extra  stay  with  the  parent  unit. 

C  Assigns  the  operators  sequentially  to  the  valid  move 

troops.  If  there  are  more  operators  than  move  troops 
than  the  sequential  assignment  continues  until  all 
operators  are  assigned. 

G  The  operator  must  have  specific  assignment 

instructions . 

D  Divides  the  operators  among  the  valid  move  troops. 

3.3.10.1.5.2  The  second  subelement  is  numeric,  and  identifies 
the  number  of  operators  to  be  assigned  to  each  move  troop.  This 
number  is  used  only  with  '  S*  above. 

3.3.10.1.6  MU  Order  Field.  The  mu_order  (move  unit  order)  field 
is  a  one  numeric  ASCII  character  field  which  indicates  the  order 
of  priority  of  move  units.  There  is  a  limit  of  five  move  units, 
therefore,  valid  entries  are  1-5. 

3.3.10.1.7  MU  SRC  Num  Field.  For  a  description  of  the 
mu_src_num  (move  unit  SRC  number)  field,  see  paragraph  3. 3. 1.1. 2. 

3.3.11  CodeGrouo  File.  This  file  describes  the  various  code 
groups  contained  in  the  nomenclature  file.  There  are  currently 
16  records  stored  in  this  file. 

3.3.11.1  CodeGroup  Record.  The  codegroup  record  is  29  bytes 
long  and  contains  five  fields  that  are  uniquely  keyed  on  the 
code_group  field. 
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3.3.11.1.1  Code  Group  Field.  The  code_group  field  is  a  two 
numeric  ASCII  character  field.  This  field  provides  the  numeric 
representation  of  the  type  codes  contained  in  the  nomenclature 
file.  Example:  01  =  Operators,  92  =  Vehicles.  There  are 
currently  16  unique  code  groups  in  this  file.  These  are  shown  in 
table  12 . 

TABLE  11.  Code  Group  Table 


Grout) 

Title 

Lenath 

Nomen 

Class 

01 

Operator  Name 

4 

15 

N 

33 

Major  Equipment  (MEQ) 

3 

24 

Y 

35 

Component  ( CMP ) 

3 

24 

Y 

40 

Antenna  (ANT) 

3 

24 

Y 

42 

Ant  Polarization  (POL) 

1 

24 

N 

44 

Emitter/Receptor  (EMT) 

1 

24 

N 

46 

Posture  (POS) 

1 

25 

N 

47 

Data  Sets  (DS) 

1 

35 

N 

50 

Modulation  (MOD) 

5 

52 

N 

52 

Antenna  Directivity 

1 

24 

N 

60 

Comm  Security  Equip 

2 

17 

N 

65 

System  Identification 

2 

15 

N 

66 

Net  Function  (FUNCT) 

1 

24 

N 

80 

Security  (SEC) 

1 

28 

N 

87 

Equipment  Status  (STA) 

1 

40 

N 

92 

Vehicle  (VEH) 

3 

40 

Y 

3.3.11.1.2  Title  Field.  The  Title  field  is  a  24  alphanumeric 
ASCII  character  field  which  provides  the  plain  english  title  of 
the  various  code  groups. 

3.3.11.1.3  Code  Length  Field.  The  code_length  field  is  a  one 
numeric  ASCII  character  field  which  provides  the  numeric  length 
of  the  code  field  of  the  various  type  codes. 

3.3.11.1.4  Nomen  Length  Field.  The  nomen_length  field  is  a  two 
numeric  ASCII  character  field  which  provides  the  numeric  length 
of  the  nomenclature  field  of  the  various  type  codes. 

3.3.11.1.5  Class  Rea  Field.  The  class_req  field  is  a  one 
alphabetic  ASCII  character  field.  This  field  states  whether  the 
various  type  codes  could  possibly  be  classified. 

3.3.12  Nomenclature  File.  This  file  contains  all  the  codes  and 
their  meanings.  Only  the  codes  contained  in  this  file  are 
considered  valid. 

3.3.12.1  Nomenclature  Record.  The  nomenclature  record  is  62 
bytes  long  and  contains  four  fields  that  are  uniquely  keyed  on 
the  code_group  and  code  fields. 
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3.3.12.1.1  Code  Group  Field.  For  a  description  of  the 
code_group  field,  see  paragraph  3.3.11.1.1*. 

3.3.12.1.2  Code  Field.  The  code  field  is  a  five  alphanumeric 
ASCII  character  field.  This  field  contains  the  codes  that  are 
used  in  the  coding  of  GUF  records.  Only  the  codes  contained  in 
this  field  are  considered  valid. 

3.3.12.1.3  Nomenclature  Field.  The  nomenclature  field  is  52 
alphanumeric  ASCII  character  field  which  contains  the  plain 
english  representation  of  the  code  field. 


3.3.12.1.4 


For  a  description  of  the  sec  class 


field,  see  paragraph  3. 3. 1.1.1. 

3.3.13  Description  File.  This  file  contains  a  plain  english 
description  of  some  of  the  coded  items.  Not  all  coded  items 
require  a  description;  the  nomenclature  field  is  sufficient. 

3.3.13.1  Description  Record.  The  description  record  is  264 
bytes  long  and  contains  three  fields  that  are  uniquely  keyed  on 
the  code_group  and  code  fields. 

3.3.13.1.1  Code  Group  Field.  For  a  description  of  the 
code_group  field,  see  paragraph  3.3.11.1.1. 


3.3.13.1_2  Code  Fieli 
paragraph  3.3.13.1.2. 


For  description  of  the  code  field,  see 


3.3.13.1.3  Description  Field.  The  description  field  is  a  255 
alphanumeric  ASCII  character  field  which  provides  a  plain  english 
description  of  appropriate  coded  items. 

3.3.14  LineNumbs  File.  The  linenumbs  file  contains  a  record  for 
each  item  in  the  nomenclature  file  that  can  be  identified  by  a 
line  identification  number. 

3.3.14.1  LineNumbs  Record.  The  linenumbs  record  is  13  bytes 
long  and  contains  three  fields  that  are  uniquely  keyed  on  the 
code__group  and  code  fields. 

3.3.14.1.1  Code  Group  Field.  For  a  description  of  the 
code_group  field,  see  paragraph  3.3.11.1.1. 

3.3.14.1.2  Code  Field.  For  a  description  of  the  code  field,  s_e 
paragraph  3.3.11.1.2. 

3.3.14.1.3  Line  ID  Num  Field.  The  line_id_num  (line  identifi¬ 
cation  number)  field  contains  line  number  from  the  TOE  or  other 
supply  documents,  that  identifies  the  associated  piece  of  equip¬ 
ment. 
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3.3.15  Ptab  File.  This  file  provides  all  the  possible  legal 
combinations  of  major  equipments,  components,  antennas,  and 
vehicles.  This  file  currently  contains  4080  records  that  are  12 
bytes  long  and  is  stored  in  an  BTREE  structure  that  is  uniquely 
keyed  on  the  meq  code,  comp  code,  ant  code,  and  vehicle  code 
fields. 


3.3.15.1  Ptab  Record.  The  ptab  record  is  12  bytes  long  and 
contains  four  fields  that  are  uniquely  keyed  on  the  meq_code, 
comp_code,  ant_code,  and  vehicle_code  fields. 

3.3.15.1.1  Mea  Code  Field.  For  the  description  of  the  meq_code 
field,  see  paragraph  3.3.5.1.11. 


3.3.15.1.2  Comp  Code  Field.  For  a  description  of  the  comp_code 
field,  see  paragraph  3.3.5.1.12. 


3.3.15.1.3  Ant  Code  Field.  For  a  description  of  the  ant_code 
field ,  see  paragraph  3 . 3 . 6 . 1 . 4 . 


3.3.15.1.4  Vehicle  Code  Field.  For  a  description  of  the 
vehicle_code  field,  see  paragraph  3. 3. 6. 1.4. 


3.3.16  Confia  ref  File.  This  file  contains  a  single  record  for 
each  legal  combination  of  a  vehicle  with  one  or  more  major 
equipment  items.  The  records  in  the  file  are  53  bytes  long  and 
are  stored  in  an  ISAM  structure  that  is  uniquely  keyed  on  the 
vcode  and  config  fields. 


3.3.16.1  Vcode  Field.  See  paragraph  3. 3. 6. 1.4. 

3.3.16.2  Confia  Field.  The  config  field  is  a  50-alphanumeric 
text  field  that  identifies  a  particular  configuration  of  radios. 
The  current  convention  is  that  the  config  is  formed  by  combining 
a  string  for  each  meq_code  (para  3.3.5.1.11).  The  strings  are 
formed  from  the  meq_code  with  a  numeric  count  prefix  when  the 
count  is  greater  than  one. 

3.3.17  Config  def  File.  This  record  contains  one  record  for 
each  kind  of  major  equipment  item  that  is  included  in  a 
particular  vehicle  configuration.  The  file  currently  contains 
970  records  that  are  stored  in  an  ISAM  structure  uniquely  keyed 
on  config  and  ecode. 

3.3.17.1  Config  Field.  See  paragraph  3.3.16.2. 

3.3.17.2  Ecode  Field.  The  ecode  field  is  the  meq_code  field 
(para  3 . 3 . 5. 1. 11) . 

3.3.18  Egp  def  File.  The  eqp_def  file  contains  one  or  more 
records  /for  every  defined  value  of  the  major  equipment  code. 
There  is  one  record  for  each  kind  of  component  that  is  contained 
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V, 
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in  the  major  equipment  item.  This  file  currently  contains  437 
10-byte  records  stored  in  a  hash  structure  and  indexed  on  ecode.  ^ 

3.3.18.1  Ecode  Field .  See  paragraph  3.3.5.1.11.  y. 

,  & 

3.3.18.2  Ccode  Field.  See  paragraph  3.3.5.1.12. 

3.3.18.3  N  Field.  The  n  field  is  a  one-byte  positive  nonzero 
integer  field  signifying  the  number  of  a  particular  component 
included  in  a  major  equipment  item. 

3.3.19  Comp  def  File.  The  comp_def  file  contains  a  single 
record  for  every  defined  type  of  component.  This  file  currently 
contains  294  57-byte  records  stored  in  a  BTREE  structure  that  is 
keyed  uniquely  on  code. 


3.3.19.1  Code  Field.  See  paragraph  3.3.5.1.12. 

3.3.19.2  Emit  code  Field.  See  paragraph  3.3.5.1.13. 


vt 
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3.3.19.3  Nomen  Field.  See  paragraph  3.3.12.1.3. 

3.3.19.4  Class  Field.  See  paragraph  3.3.12.1.4. 

3.3.20  Ed  master  File.  The  eqjnaster  file  contains  selected  TOE 
header  records  from  VTAADS .  The  format  of  TOE  header,  paragraph, 
equipment,  and  personnel  records  is  shown  in  figure  4.  The  file 
contains  five  60-byte  records  stored  in  a  heap. 


3.3.20.1  TOE  Number  Field.  The  field  contains  characters  3-11 
of  the  SRC  number  (para  3 . 3 . 1. 1. 2 . 6) .  TOE  number  is  stored  in 
ASCII  format.  X 


3.3.20.2  Title  Field.  This  47-character  field  contains  the  TOE  K: 

title. 

3.3.20.3  Rtvpe  Field.  The  rtype  field  is  the  single-character  7- 

"A"  for  record  type.  £ 

3.3.20.4  SecurClass  Field.  The  secur_class  field  is  a  one- 
character  security  code,  normally  "U"  for  unclassified. 

3.3.21  Paragraph  File.  The  paragraph  field  contains  the  VTAADS 
paragraph  header  records.  There  are  currently  31  3 5 -byte  records 
stored  in  a  heap.  \\ 

3.3.21.1  TOE  number  Field.  See  paragraph  3.3.20.1.  y. 

3.3.21.2  Para  num  Field.  The  para_num  field  is  a  two-character 
numeric  paragraph  number  with  leading  zeroes;  it  is  stored  in 
ASCII  format. 
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3.3.21*3  Title  Field.  The  title  field  is  a  21-character  para- 


VTAADS  Tape  Format 


DBDD-C005T004D7 


3.3.22  Personnel  File.  The  personnel  file  contains  the  VTAADS 
personnel  records  with  selected  fields.  There  are  currently  202 
43-byte  records  stored  in  a  compressed  heap. 


3.3.22.1 


3.3.22.2 


3.3.22.3 


See  paragraph  3.3.20.1. 

See  paragraph  3.3.21.2. 

This  field  is  a  22-character  title. 


3.3.22.4  Grade  Field.  This  field  is  a  2-character  ASCII  code 
denoting  grade  or  rank,  such  as  E7. 

3.3.22.5  MOS  Field.  This  field  is  a  5-character  description 
indicating  military  occupational  specialty. 

3.3.22.6  Kount  Field.  This  field  is  a  one-byte  positive 
nonzero  integer  indicating  the  number  of  personnel  of  this  title 
when  the  unit  is  at  full  strength  level. 

3.3.23  Equipment  File.  This  file  contains  the  VTAADS  equipment 
records.  There  are  currently  276  68-byte-long  records  stored  in 
a  hash  structure.  Nonradio  equipment  is  included. 


3.3.23.1 


See  paragraph  3.3.20.2. 


3.3.23.2  Para  num  Field.  See  paragraph  3.3.21.2. 

3.3.23.3  Nomenclature  Field.  This  field  is  a  34-character 
nomenclature  naming  the  equipment  item. 

3.3.23.4  Kount  Field.  This  field  is  a  one-byte  integer 
indicating  the  count  for- this  particular  equipment  item  in  a 
specific  paragraph  when  the  unit  is  at  full  strength. 


3.3.23.5 


See  paragraph  3.3.14.1.3. 


3.3.23.6  Kind  Field.  This  field  is  a  12-character  description 
which  indicates  whether  an  equipment  item  is  a  vehicle,  COMSEC, 
radio/radar,  or  other.  The  legal  values  of  this  field  are 
COMSEC,  VEHICLE,  RADIO/RADAR,  and  OTHER. 


3.3.24  Rai 
3 . 3 . 2 . 2 . 4  . 

3.3.24.1  ' 


!.  This  file  is  a  view.  See  paragraph 


See  paragraph  3.3.20.2. 


3.3.24.2  Para  num  Field.  See  paragraph  3.3.21.2. 

3.3.24.3  Nomenclature  Field.  See  paragraph  3,3.1.23.3 


3.3.24.4. 


See  paragraph  3.3.23.4 
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3.3.24.5  Code. .Field.  This  field  is  the  major  equipment  code. 
See  paragraphs  3.3.5.1.11  and  3.3.12.1.2. 

3.3.24.6  Line  id  num  Field.  See  paragraph  3.3.14.1.3. 

* 

3.3.25  Vehicle,  File.  This  file  is  a  view.  See  paragraph 
3. 2. 2. 5. 

3.3.25.1  TOE  number  Field.  See  paragraph  3.3.20.2. 

3.3.25.2  Para  num  Field.  See  paragraph  3.3.21.2. 

3.3.25.3  Nomenclature  Field.  See  paragraph  3.3.23.3. 

3.3.25.4  Kount  Field.  See  paragraph  3.3.22.6. 

3.3.25.5  Code  Field.  See  paragraphs  3.3.12.1.2. 

3.4  Data  Base  References.  To  be  determined. 
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NOTES 


6.1  Abbreviations  and  Acronyms.  The  following  is  a  list  of 
abbreviations  and  acronyms  used  in  this  document. 

BTO  Bell  Technical  Operations 

CEOPS  Communications-Eiectronics 

Operator  Positioning  System 
Comsec  Communications  Security 

CEWI  Communications,  Electronic  Warfare,  and  Intelligence 

CSCI  Computer  Software  Configuration  Item 

DBDO  Data  Base  Design  Document 

Equel  Embedded  QUEL 

EW  electronic  warfare 

GDB  Generic  Data  Base 

GDES  Generic  Data  Entry  System 

GHz  gigahertz 

GUES  Generic  Unit  Entry  System 

GUF  Generic  Unit  File 

HF  high  frequency 

INGRES  Interactive  Graphics  and  Retrieval  System 

IR  infrared 

LF  low  frequency 

MEQ  Ma j  or  Equipment 

MF  medium  frequency 

MFDC  Master  File  of  Deployment  Constraints 

MSE  Mobile  Subscriber  Equipment 

MU  Move  Unit 

NCS  Net  Control  Station 

NIC  Net  Information  Code 

OAC  Operator  Assignment  Code 

Ptab  Power  and  Antenna  Table 

QUEL  Query  Language 

RF  Radio  Frequency 

RTI  Relational  Technology,  Inc. 

SHF  super  high  frequency 

SpecOpr  Special  Operator  Distribution 

SRC  Standard  Requirements  Code 

TOE  Table (s)  of  Organization  and  Equipment 

UHF  ultra  high  frequency 

URC  Unit  Relationship  Code 

USAEPG  US  Army  Electronic  Proving  Ground 

VHF  very  high  frequency 

VLF  very  low  frequency 

VTAADS  VERTICAL,  the  Army  Authorized  Document  System 
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U.S.  Army  Test  and  Evaluation  Command 
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